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 drecursos 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 estandares 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 institucion 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...

  1. No aceptar el establecimiento de conexi�n SMTP incluidas en listas de bloqueo internacional especialmente la zona ZEN de Spamhaus

    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: 554. Access blocked using sbl-xbl.spamhaus.org. SMTP. Policy of RedIRIS in http://www.rediris.es/mail/aupREDIRIS.htmlContact < postmaster@... >

  2. 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@... >

  3. 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@... >

  4. 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...

  5. 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

    MotivoLos 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...

  6. 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

  7. 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@... >

  8. 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...

  9. 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

  10. 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)

  11. 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...

  12. 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.

  13. 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

Esta página ha sido firmada digitalmente usando PGP