Recomendaciones de tráfico SMTP entrante en en la Comunidad Académica RedIRIS


 Version: v1.0
Fecha: Diciembre 2006

Introducción

El tráfico SMTP gestionado por los servidores de correo se ha incrementado notablemente a pesar de las medidas anti-spam implementadas en los últimos años. Un porcentaje muy alto de este tráfico (50-60%) es tráfico oscuro que se suele procesar . Este tráfico es ocasionado por conexiones procedentes de IPs comprometidas con algún tipo de malware que implementa capacidad de instalar motor SMTP propio lo cual se emplea para difundir spam, virus, ataques de diccionario (Directory Harvest Attaks) , denegación de Servicio (DoS), mensajes a destinatarios no existentes. La mayor parte de las soluciones de seguridad en el correo electrónico no tienen en cuenta este tráfico indeseado a través del puerto 25 que es aceptado, analizado y rechazado con la consiguiente usurpación de uso de recursos necesarios para su procesamiento.

Este tipo de tráfico SMTP inútil se caracteriza por el incumpliento de estándares de Internet, por lo que puede ser reducido con una serie de medidas básicas implementadas en los MTAs que recogen el correo desde Internet.

Objetivo

El actual problema de seguridad en el correo electrónico es lo suficientemente grave como para tomar medidas comunes y consensuadas por parte de una Comunidad homogénea como es la comunidad académica española (RedIRIS). El objetivo de estas recomendaciones es definir un marco común consensuado para toda la Comunidad RedIRIS. Estas Recomendaciones fueron aprobadas en la Reunión IRIS-MAIL/25 (Noviembre 2006, Granada) y están pensadas como pautas a seguir por las Servicios de Correo Electrónico de instituciones de la comunidad académica española.

Las recomendaciones de este documento son:

  •     Independientes de los productos utilizados como MTAs (relays)
  •     Complementarias a cualquier configuración y política de seguridad de las instituciones y
  •     Convergentes con los estándares de Internet, RFCs, así como con las recomendaciones internacionales de Buenas Práticas para operadores de Red.

Las Recomendaciones de este documento Permiten:

  •     Disponer de una política común en RedIRIS
  •     Ser la base para construir un correo electrónico mas seguro en la comunidad científica
  •     Estar preparados para los nuevos protocolos que están por llegar (SPF,DKIM,CSV,Sender-ID etc.)
  •     Servir de modelo a otros operadores de correo electrónico.


Cada institución es libre de definir sus políticas anti-spam pero es conveniente aconsejable implementar estas Recomendaciones para hacer un frente común al spam de toda la Comunidad RedIRIS. Esperamos que un amplio despliegue de estas Recomendaciones tenga impacto directo en una reducción de los recursos de los servidores, en los buzones de los usuarios y en la propia satisfacción del servicio.

Para unificar esta política, algunas de las recomendaciones especifican códigos de respuesta comunes del protocolo SMTP, pudiendo opcionalmente añadirlos a las configuraciones de los MTAs.

Política de tráfico SMTP entrante en la Comunidad Académica RedIRIS

Una transacción SMTP según el estándar RFC821 tiene varias etapas: Conexión (CONNECT), Presentación (HELO), Emisor (MAIL FROM), Receptor (RCP TO:) y Contenidos (DATA). Estas recomendaciones van enfocadas a controles en el Sobre de las transacciones SMTP no a los Contenidos. Los controles SMTP en el Sobre tienen como objetivo verificar la validez de la dirección del servidor de correo remoto que solicita establecer la transacción SMTP.

Conexión (CONNECT)

Se recomienda...

  •     No aceptar el establecimiento de conexión SMTP incluidas en la lista de reputacion: IRISRBL

Motivo: bloquear conexiones SMTP procedentes de IPs etiquetadas como no deseables a nivel internacional o local, asi como IPs dinámicas residenciales que utilizan inconscientemente el protocolo SMTP.

Código:

strong.dnsbl.rediris.es 550 Service unavailablei; IP 1.2.3.4 has been blocked using RedIRIS Reputation Service (IRISRBL). You have to send a email to postmaster@su-institucion.es.+info http://www.rediris.es/irisrbl/dnsbl.es.html

  •     No aceptar el establecimiento de conexión SMTP asociadas a conexiones residenciales de tipo ADSL/cable dinámica que no son servidores de correo autorizado

Motivo: Hay datos contrastados que un porcentaje muy alto de las fuentes de malware proceden de IPs de asignación dinámica. Debido al alto tráfico SMTP generado por este tipo de IPs es complicado eliminarlo sin provocar gran impacto en los recursos y calidad del servicio.

    Si usted fuera un cliente con un relay en una de estas IP y si desea realmente un servidor de correo electrónico es muy recomendable que cambie la resolución inversa de dicha IP por otro dominio.
Código:

554. SMTP Policy of RedIRIS doesn't accept traffic generic cable/dsl hostnames. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.html. Contact < postmaster@... >

  •   No aceptar el establecimiento de conexión SMTP desde IPs que no dispongan de resolución inversa.

Motivo: La resolución inversa de una IP forma parte de los RFCs y es un síntoma contrastado de configuración incorrecta del servicio de correo. Es una caracteristica típica en la distribubución de malware.
Código:

554. No reverse DNS configuration for IP. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.htmlContact < postmaster@... >

  •     No aceptar el establecimiento de conexión SMTP desde IPs asociadas a listas de bloqueo locales

Motivo: Es necesario que cada institución bloquee conexiones externas que no cumplen sus politicas de seguridad.
Código:

554. 5.7.1 Relaying denied. IP/domain is banned

    Presentación (HELO/EHLO)

    Se recomienda...

    No aceptar el establecimiento de conexión SMTP cuyo valor HELO/EHLO sea nulo o sin canonificar tal como se especifica en el apartado 4.1.1.1 de RFC2821

    Motivo: Los estandares SMTP (RFC2821) indican claramente la obligación de colocal un valor correcto al campo HELO/EHLO

    Código:

554. 5.7.1 Helo command rejected: Host not found. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.htmlContact < postmaster@... >

    Emisor (MAIL FROM)

    Se recomienda...

    No aceptar el establecimiento de conexión SMTP cuyo valor MAIL FROM: sea un dominio no existente
Motivo: En un mensaje entrante si no existe un dominio emisor correcto no serás posible responder.

Código:

554 Access denied . Domain of sender address does not resolve. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.html

No aceptar el establecimiento de conexión SMTP cuyo valor MAIL FROM: sea un dominio local.


    Motivo: Una transaccion SMTP desde el exterior no puede proceder de una direccion local

    Código:

554. Access denied. Domain of sender address its a local domain. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.htmlContact < postmaster@... >

    Chequear la responsabilidad del servidor remoto con SPF, DKIM, SenderID o Whitelisting para comprobar que el correo procede del servidor oficial responsable del dominio.

    Motivo: RedIRIS apuesta por el despliegue de estas nuevas tecnologías de autenticación del emisor.

    Receptor (RCPT TO)

    Se recomienda...

    No aceptar el establecimiento de conexión SMTP si el dominio destinatario no es de nuestra responsabilidad.

    Motivo: Una transaccion SMTP externa no debe ser aceptada si va destinada a un dominio que no es de nuestra responsabilidad.

    Código:

554. Relay access denied. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.html

  •     No aceptar el establecimiento de conexión SMTP si el la dirección destinataria no está permitida Motivación:Las bases de datos de los usuarios no suele estar ubicada en el relay principal, por lo que es muy recomendable que sea capaz de chequear en tiempo de transacción SMTP la existencia de la parte de usuario para interumpir la conexión.

    Otros (flujos)

    Es recomendable disponer de un sistema de control de flujos SMTP que permita controlar un número inusualmente elevado de conexiones SMTP comparando IP,From,To.

    Motivo: La implementación del filtro SMTP de salida puede tener un efecto pernicioso en el servicio local en caso de PCs comprometidos que intenten establecer conexiones SMTP
   

Contenidos (DATA)

    Se recomienda...

    Definir un tamaños máximo de mensaje superior a 50 M que permitirá el intercambio de ficheros ligeros entre instituciones de la Comunidad RedIRIS.

    Analizar el contenido del correo en busca de malware. Este control se aplicará despues de haber sido analizado la reputación de la IP origen de la transaccion SMTP.

Regulaciones internacionales

    The Australian Spam Act
    http://www.comlaw.gov.au/ComLaw/Legislation/ActCompilation1.nsf/0/E9920A4E670D0FC8CA25702600124DC5?OpenDocument

    Managing Port 25 for Residential or Dynamic IP Space Benefits of Adoption and Risks of Inaction
    http://www.maawg.org/port25

    The Canadian Task Force on Spam
    http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/h_gv00248e.html

    EU Electronic Communications Directive
    http://europa.eu/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf

    Anti-Spam Technical Alliance Technology and Policy Proposal
    http://docs.yahoo.com/docs/pr/pdf/asta_soi.pdf

    Good Practice in Minimising E-mail Abuse. RIPE
    http://www.ripe.net/ripe/draft-documents/bcp-abuse.html