Exchange Server 2007

Contra el correo no deseado y la suplantación de identidad con un Id. de remitente

Craig Spiezle and Alexander Nikolayev

Resumen:

• Conceptos básicos del Id. de remitente
• Configuración del Id. de remitente en Exchange Server
• Ventajas de la autenticación

Muchas tecnologías de identificación y filtrado se han desarrollado en respuesta a la creciente amenaza del correo no deseado. Para ser eficaces, formulan determinadas preguntas acerca de cada mensaje de correo electrónico, como por ejemplo,

quién lo envió. Desafortunadamente, no siempre es fácil responder a la cuestión fundamental de quién envió el mensaje. Normalmente, el correo electrónico se envía por Internet sin ninguna autenticación del remitente ni de los equipos que actúan en nombre del remitente. Lo cierto es que resulta fácil enviar un mensaje de correo electrónico fingiendo ser otra persona y que no existe ningún método automatizado para detectar mensajes simulados.

El Protocolo simple de transferencia de correo (SMTP), que se usa para enviar y recibir correo electrónico, no se diseñó para comprobar el remitente de un mensaje de correo electrónico. Aprovechando esta vulnerabilidad tecnológica, puede insertarse cualquier nombre y dirección como remitente. Por consiguiente, las medidas de filtrado de contenido o de protección contra el correo no deseado no pueden depender únicamente de la información del encabezado para garantizar que los mensajes realmente procedan de la dirección indicada.

La autenticación de correo electrónico intenta resolver específicamente esta vulnerabilidad. A través de la autenticación, tanto los sistemas de envío como de recepción de correo electrónico validan los mensajes que proceden de los dominios mostrados. Esto facilita que las organizaciones puedan filtrar el correo no deseado de forma eficaz y también garantiza que el correo electrónico legítimo llegue hasta los destinatarios pertinentes.

Actualmente, existen dos enfoques libres de regalías en la autenticación de correo electrónico: el marco de Id. de remitente (SIDF) y DomainKeys Identified Mail (DKIM). SIDF es una solución basada en el protocolo de Internet (IP) que se creó a partir de la fusión de Sender Policy Framework (SPF) y Microsoft Caller ID for E-Mail. En abril de 2006, Internet Engineering Task Force (IETF) publicó las especificaciones de Id. de remitente como RFC 4405-4408. Una coalición de participantes del sector y de empresas, incluido Microsoft, recomienda la implementación de SIDF en función de factores que incluyan valor empresarial y técnico, estabilidad, madurez, facilidad de implementación, impacto mínimo en el rendimiento saliente o entrante e interoperabilidad con el ecosistema de correo electrónico para los entornos empresariales y los ISP.

DKIM es la fusión de Yahoo! Especificaciones de DomainKeys e Identified Internet Mail (IIM) de Cisco Systems Incorporated. En enero de 2006, IETF aprobó la creación de un grupo de trabajo DKIM y, actualmente, está revisando la especificación.

Aunque no existe una solución perfecta para combatir el correo no deseado, SIDF representa una importante iniciativa en el sector para combatir los dominios simulados. Por lo tanto, es un componente clave en la reducción del correo no deseado y los ataques de suplantación y en el aumento de la confianza en línea. Las organizaciones de todo el mundo están adoptando SIDF rápidamente. Hoy día, más de 5,5 millones de empresas y propietarios de dominios han publicado registros SPF y más de 600 millones de usuarios están protegidos por SIDF. Actualmente, más de un tercio del volumen de correo electrónico diario mundial es autenticado por SIDF y compatible con éste.

El desarrollo de SIDF y su adopción en todo el mundo no serían posibles sin la colaboración y el apoyo de muchas organizaciones y empresas, como por ejemplo, AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, etc.

Descripción del Id. de remitente

Algunas encuestas del sector indican que más del 95 por ciento de las operaciones de suplantación de identidad proceden de dominios simulados y tienen direcciones de correo electrónico de destinatarios simulados. Aquí radica la enorme diferencia que distingue a SIDF respecto al procesamiento de la protección contra el correo no deseado. Por sí mismo, SIDF no puede solucionar el problema del correo no deseado, pero contribuye enormemente a minimizar sus consecuencias, así como los ataques de suplantación. SIDF no evita el envío de correo no deseado. Sin embargo, facilita en gran medida su detección. El marco ayuda a los remitentes de correo electrónico a proteger sus nombres de dominio, su reputación y sus marcas. Proporciona una base sólida para la toma de decisiones de filtrado en función de la reputación y el comportamiento de correo electrónico del remitente.

El Id. de remitente sirve para comprobar que los mensajes de correo electrónico se originan en los dominios de Internet que muestran. Esto se lleva a cabo comprobando la dirección del servidor que envía el correo electrónico con una lista de servidores registrados a los que el propietario del dominio ha autorizado para enviar correo electrónico. La comprobación la realiza automáticamente el proveedor de servicios de Internet (ISP) o el servidor de correo del destinatario antes de que el mensaje se envíe a la bandeja de entrada del usuario.

Tenga en cuenta que el Id. de remitente o cualquier otro mecanismo de autenticación no sustituye a los sistemas de filtrado de contenido. Ni SIDF ni DKIM exploran el contenido real del mensaje. Por el contrario, la autenticación notifica al sistema de correo entrante la validación del mensaje, si éste procede del destinatario indicado. Dado que la mayor parte del correo no deseado y de los ataques de suplantación no proceden realmente del dominio mostrado, este enfoque puede ayudar a identificar automáticamente estos mensajes y separarlos del flujo de correo entrante.

En SIDF, el registro SPF proporciona un registro de texto sencillo de todos los servidores de correo saliente asociados a un dominio, así como sus direcciones IP respectivas. Una organización publica el registro SPF en su archivo de zona de servidor DNS y, a continuación, los servidores de correo de destino lo comprueban. Un registro SPF se establece rápida y fácilmente, y además es gratis. El asistente para registros SPF del marco de Id. de remitente proporciona un proceso paso a paso para encuestar a los servidores de correo de un dominio y crear registros personalizados preparados para su publicación. En microsoft.com/senderid encontrará información detallada sobre cómo publicar un registro SPF. Se puede tener acceso directo al asistente desde microsoft.com/senderid/wizard.

El servidor de correo SMTP de recepción hace ping en el archivo de zona del dominio del DNS para comprobar si existe un registro SPF. Una vez encontrado, la dirección IP del servidor de envío se confronta con las direcciones IP de la lista. Si existe una coincidencia, el mensaje se valida como auténtico. Si, por otro lado, el registro SPF del domino del remitente no coincide con la dirección IP de la que procede el mensaje, se produce un error en el mensaje, lo que ocasiona una puntuación negativa y la posibilidad de colocar el mensaje en la carpeta de correo no deseado. La figura 1 muestra este proceso.

Figura 1** Comprobación de registros SPF para los mensajes entrantes **(Hacer clic en la imagen para ampliarla)

Una vez etiquetado el mensaje, SIDF habilita al servidor de correo destinatario para analizar el mensaje en función de comportamientos anteriores, la reputación del remitente, su contenido y otros criterios que pueden definirse en caso necesario. Esta capacidad proporciona medidas de seguridad adicionales. Por ejemplo, las personas que envían correo no deseado pueden registrar dominios y registros SPF publicados que sean parecidos a fin de engañar a los usuarios y la red receptora haciéndoles creer que el correo procede de un remitente legítimo. Y aunque el mensaje de correo electrónico pueda pasar la comprobación de autenticidad, la reputación del remitente como persona que envía correo no deseado es suficiente para bloquear el mensaje, considerarlo como correo no deseado o eliminarlo.

Opciones de implementación del Id. de remitente

La autenticación del correo electrónico saliente a través de SIDF no requiere cambios de infraestructura ni actualizaciones de software, y no es específica del software de cliente ni de servidor. No obstante, una organización que desee incorporar la autenticación entrante para proteger a la propia organización y a los empleados deberá actualizar su sistema entrante y el Agente de transferencia de mensajes (MTA), e implementar software o un dispositivo que sea compatible con SIDF. La mayoría de los MTA comerciales más importantes de código abierto y de proveedores de protección contra el correo no deseado, incluido Microsoft® Exchange Server y Exchange Hosted Filtering, ofrecen soluciones integradas.

Microsoft ha integrado SIDF en todos sus productos de mensajería, entre los que se incluye Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express y los clientes de mensajería y colaboración de Office Outlook.

No obstante, ni siquiera Microsoft está exento de recibir correo no deseado. Por término medio, el tráfico entrante diario en Microsoft es aproximadamente de 15 millones de mensajes, y durante recientes ataques de correo no deseado hemos comprobado que se recibe de dos a cuatro veces más ese volumen. En un entorno de este tipo, la mejor vía de protección contra el correo no deseado consiste en una cuidadosa implementación de las tecnologías disponibles.

Microsoft está ejecutando internamente una solución de protección contra el correo no deseado de Exchange Server basada en el filtro de Id. de remitente de Exchange Server 2003 y el agente de Id. de remitente de Exchange Server 2007. En ambas versiones de Exchange Server, el estado del Id. de remitente se basa en la evaluación del registro de Id. del remitente situado en los servidores DNS correspondientes. El dominio real se determina examinando los encabezados de mensaje RFC 2822 según esta prioridad:

1. Resent-Sender
2. Resent-From
3. Sender
4. From

El dominio del remitente (o la entidad más reciente que sea responsable de insertar un mensaje en el flujo de mensajería, dado que los sistemas de correo electrónico pueden reenviar correo legítimamente en nombre de otros servidores de correo) se determina localizando la primera definición de los encabezados recién mencionados en el orden definido. Si no se encuentra ninguno de estos encabezados, SIDF usará el valor MAIL FROM de SMTP RFC 2821.

Configuración del Id. de remitente

En Exchange Server 2007, el agente de Id. de remitente se puede habilitar en servidores que tengan instalada la función de transporte perimetral. Si el agente de Id. de remitente está habilitado, filtrará los mensajes que lleguen a través de los conectores de recepción; todo el tráfico entrante (procedente de fuentes externas) no autenticado estará sujeto al procesamiento de Id. de remitente. En Exchange Server 2003, el estado del Id. de remitente se mantiene de servidor a servidor en el blob EXCH50; en Exchange Server 2007 también se ha agregado a los metadatos de los mensajes. En su destino final, ambos se convertirán en una propiedad MAPI para el uso futuro de los clientes.

La configuración de filtrado de Id. de remitente en Exchange Server 2003, disponible en las propiedades de entrega de mensajes, sólo consiste en especificar cómo Exchange Server maneja la validación con errores.

Para habilitar el Id. de remitente en Exchange Server 2007, abra la Consola de administración de Exchange de un servidor que tenga configurada la función de transporte perimetral, seleccione la ficha Protección contra el correo no deseado, el Id. de remitente y, en el panel Acciones, haga clic en Habilitar o Deshabilitar para alternar el agente de Id. de remitente como se muestra en la figura 2. También puede usar el Shell de administración de Exchange para habilitar o deshabilitar el Id. de remitente como se muestra en la figura 3.

Figura 2** Controles de la Consola de administración de Exchange para el agente de Id. de remitente en Exchange Server 2007 **(Hacer clic en la imagen para ampliarla)

Figura 3** Habilitación del Id. de remitente mediante el Shell de administración de Exchange **(Hacer clic en la imagen para ampliarla)

El cuadro de diálogo Propiedades de ID del remitente refleja el estado del agente, que puede ser habilitado o deshabilitado. La ficha Acción proporciona opciones muy similares a las opciones disponibles en Exchange Server 2003 (consulte la figura 4).

Figura 4** Propiedades de las acciones de agente de Id. de remitente en Exchange Server 2007 **(Hacer clic en la imagen para ampliarla)

En cuanto a la implementación y funcionalidad del Id. de remitente, no existen diferencias importantes entre Exchange Server 2003 y Exchange Server 2007 y tanto el filtro de Id. de remitente (en Exchange Server 2003) como el agente de Id. de remitente (en Exchange Server 2007) usan el mismo algoritmo subyacente para la extracción y la comprobación. El rango de acciones posibles también es el mismo: Eliminar el mensaje (eliminación silenciosa), rechazar el mensaje (respuesta de protocolo SMTP de nivel 500) y marcar el mensaje con el resultado del Id. de remitente y continuar el procesamiento. La última opción es la acción predeterminada en ambas versiones de Exchange Server.

En Exchange Server 2007 tanto el código de estado FAIL como TempError pueden desencadenar una acción de rechazar el mensaje (en Exchange Server 2003 sólo el código de estado FAIL puede desencadenar esta acción). El agente de Id. de remitente debe configurarse explícitamente para desencadenar la acción de rechazar el mensaje en mensajes con un código de estado TempError ya que, de forma predeterminada, esos mensajes se aceptarán en el sistema, se marcarán con el resultado de Id. de remitente y después se procesarán.

Esta opción de configuración no se muestra en la interfaz gráfica de usuario, por tanto, deberá usar el Shell de administración de Exchange para configurar las acciones de Id. de remitente para el código de estado TempError. Por ejemplo, para obligar al agente de Id. de remitente a rechazar mensajes con el código de estado TempError, ejecute el cmdlet siguiente de agente de Id. de remitente:

Set-SenderIDConfig -TempErrorAction Reject

El rango de resultados del estado de Id. de remitente y de las acciones posibles de Exchange Server 2007 es similar al rango del filtro de Id. de remitente de Exchange Server 2003 y se muestra en la figura 5.

Figure 5 Estado del Id. de remitente y acciones de Exchange Server 2007

Exchange sólo elimina (si se ha configurado con ese fin) los mensajes que dieron un error durante la comprobación del Id. de remitente. Ningún otro resultado desencadenará la eliminación de mensajes. Los mensajes entrantes que derivaron en la asignación de los estados Neutral, None, SoftFail, TempError o PermError se marcarán como corresponda y pasarán a la posterior comprobación de protección contra el correo no deseado. En algunos casos, cuando el mensaje tiene un formato totalmente incorrecto y falta la dirección IP FROM, el estado del Id. de remitente no se puede marcar en el mensaje. En esta situación, el mensaje no se descarta ni se rechaza. Por el contrario, pasa a su posterior procesamiento sin que tenga establecido el estado de Id. de remitente y se registra un evento apropiado para que se tenga en cuenta.

En Exchange Server 2007 es fácil definir los dominios de remitente y los destinatarios de Exchange Server que deben excluirse de la comprobación de Id. de remitente. Una vez más, esta opción de configuración sólo está disponible a través del Shell de administración de Exchange. Por ejemplo, para excluir el dominio contoso.com del filtrado de Id. de remitente, ejecute el comando siguiente:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

Asimismo, para excluir los mensajes enviados a destinatarios específicos de Exchange Server del filtrado de Id. de remitente, ejecute el comando siguiente:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

En Exchange Server 2007, los valores de configuración de Id. de remitente establecidos a través de cmdlets del Shell de administración de Exchange, pero no disponibles a través de la interfaz gráfica de usuario, pueden obtenerse fácilmente ejecutando el comando Get-SenderIDConfig en el Shell de administración de Exchange, como se muestra en la figura 6.

Figura 6** Cmdlets de configuración de Id. de remitente **(Hacer clic en la imagen para ampliarla)

El Shell de administración de Exchange se puede usar para comprobar manualmente y con rapidez las direcciones IP y el nombre de dominio correspondiente. Para comprobar el estado del Id. de remitente, ejecute el comando siguiente:

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

Si el dominio no existe, verá un resultado similar al que aparece en la figura 7.

Figura 7** Comprobación del estado de Id. de remitente de una dirección **(Hacer clic en la imagen para ampliarla)

Ventajas del Id. de remitente

Aparte de sus evidentes ventajas en la autenticación de mensajes de correo electrónico y la reducción de la cantidad de correo no deseado que reciben los usuarios, SIDF, como protocolo, ofrece otras ventajas. Durante su desarrollo, Microsoft se centró en varios objetivos clave, como por ejemplo, el rendimiento, el costo, la implementación y escalabilidad, y la interoperabilidad.

SIDF primero autentica un remitente de correo electrónico y, a continuación, permite que la puntuación de la reputación del remitente se aplique a los mensajes. Como resultado, es posible que se reduzca considerablemente el correo no deseado y los mensajes de correo electrónico simulados, y que se mejore la entrega de correo electrónico legítimo procedente de remitentes conocidos y de confianza. La creación de un registro SPF es gratuita, por lo tanto, cualquier organización que desee adoptar SIDF puede hacerlo fácilmente. Las organizaciones que deseen cumplir las estipulaciones de un nuevo estándar deberán poder hacerlo. Con SIDF, el cumplimiento es tan fácil como publicar un registro SPF.

SIDF se ha desarrollado para funcionar en software existente, siempre que esto sea posible. Se puede usar con una amplia gama de arquitecturas de correo electrónico y software de cliente y servidor. Para ser eficaz, un servicio de autenticación debe poder satisfacer las necesidades de los ISP de gran tamaño sencillamente como si se tratara de un servidor de correo doméstico de menor tamaño. SIDF puede admitir desde un servidor de correo electrónico hasta miles de servidores, además de las organizaciones que subcontratan sus servidores de correo electrónico a otra organización.

Los días 18 y 19 de abril de 2007 Microsoft y un consorcio del sector formado por más de 30 organizaciones y socios organizarán una cumbre sobre la autenticación & la identidad en línea en Boston, MA. Este programa de dos días revisará casos prácticos y ofrecerá una revisión técnica del Id. de remitente, en la que se detallará el valor empresarial de la autenticación del correo electrónico. Para obtener más información, visite aotalliance.org/summit2007. Además, si desea obtener información sobre herramientas y recursos, puede visitar microsoft.com/senderid y microsoft.com/exchange.

Craig Spiezle es el Director de estrategia tecnológica y programación de Windows Live Safety en Microsoft. Como director de productos para la autenticación de correo electrónico, Craig ha impulsado la incorporación del Id. de remitente en el sector. Desde su incorporación en Microsoft en 1992, Craig ha ocupado diversos puestos de administración en áreas relacionadas con marketing internacional, estrategias de soporte de productos, OEM y el desarrollo de mercado emergente.

Alexander Nikolayev es el Administrador de programas de Microsoft y tiene a su cargo los protocolos de servidor, el centro de transporte y los componentes de protección contra el correo no deseado para Exchange Server y Windows Server. Tiene un máster en administración de empresas por la Universidad de Mary. Lea las exposiciones de Alexander en el blog del equipo de Exchange en blogs.technet.com/exchange.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.