Comunicaciones

Servidores Exchange de transporte perimetral en Microsoft

Kay Unkroth

Resumen:

• La función de servidor Transporte perimetral de Exchange
• Configuración de un laboratorio de pruebas
• Agentes y eventos de transporte
• Información interna del agente

Descargar el código de este artículo: ExchangeEdge2007_10.exe (354KB)

Microsoft recibe de Internet aproximadamente 13 millones de intentos de entrega de mensajes en un día hábil promedio, y bloquea más de 10,5 millones de los mismos como no legítimos. En situaciones

críticas, tales como durante ataques de correo no deseado o brotes de virus en Internet, el volumen puede aumentar a más de 90 millones. Por supuesto, este es un dato que afecta específicamente a Microsoft, pero además el scamming, correo no deseado, phishing, virus originados en le correo electrónico, recolección de directorios, ataques de denegación de servicio distribuidos (DDoS) y problemas semejantes, no son específicos de Microsoft. Frente a dichos problemas, ¿cómo garantiza la entrega de todos los mensajes legítimos a sus usuarios mientras mantiene la afluencia masiva de contenido ilegítimo, malintencionado alejada de su entorno de mensajería?

Una manera de conseguir una protección de mensajería confiable es implementar servidores de transporte perimetral de Exchange Server 2007 y Forefront Security para Exchange Server en una red perimetral entre Internet y su entorno de producción. Esta red coloca un equipo organizado de más de 10 agentes de transporte perimetral en su perímetro para ayudarlo a proteger sus sistemas y usuarios de producción. El valor de bloquear el contenido no deseado en el primer punto posible es obvio. En una situación ideal, esto sucede aún antes de que el contenido se entregue a sus servidores, si se considera la carga que de otro modo tendría que mantener su entorno de mensajería en una situación crítica. Aún así, la protección de mensajería es mucho más que el simple bloqueo de los mensajes.

Éste es el primer artículo de una serie de dos partes que analiza la arquitectura y características clave de los agentes contra correo electrónico no deseado y agentes antivirus disponibles con Exchange Server 2007 y Forefront Security para Exchange Server. Para que las explicaciones sean realistas y prácticas, le mostraré en este primer artículo cómo construir un laboratorio de pruebas que refleje el diseño de protección de mensajería que usa Microsoft en su propio entorno de producción corporativo. A continuación, cubriré la arquitectura de transporte perimetral de Exchange Server 2007 con mayor detalle.

A través de este artículo, usaré muchos scripts y archivos por lotes para automatizar las tareas de configuración más importantes. Estos archivos incluyen comentarios que explican los pasos individuales realizados. Puede encontrar los scripts en la descarga disponible en el sitio web de TechNet Magazine en technetmagazine.com/code07.aspx.

Topología de transporte perimetral

La figura 1 ilustra el diseño de transporte perimetral que Microsoft IT implementó en el entorno de producción corporativo. Existen algunas características de diseño muy interesantes que me gustaría señalar antes de explicarle la arquitectura de transporte perimetral. Si está interesado en los detalles completos de la implementación, consulte las notas del producto IT Showcase que se mencionan en la barra lateral "Recursos de Exchange".

Figura 1** Topología de transporte perimetral en Microsoft **(Hacer clic en la imagen para ampliarla)

Cuando analice la figura 1, observará que la topología de transporte perimetral en Microsoft es completamente redundante. No existe un único punto de error en ninguna ubicación. Para equilibrar la carga, Microsoft IT usa externamente operación por turnos de DNS e internamente conectores de mensajería con múltiples cabezas de puente. También es digno de mencionar que todos los servidores de transporte (concentrador de transporte y transporte perimetral) ejecutan Forefront Security para Exchange Server para la exploración de virus. Esto permite a Microsoft IT examinar todos los mensajes entrantes, salientes e internos en cuanto los mensajes alcanzan un servidor de transporte en la topología de enrutamiento de mensajes.

Otra característica de diseño importante relacionada con la seguridad es que los servidores de transporte perimetral no forman parte del entorno corporativo de Active Directory®. De hecho, no es necesario implementar servidores de transporte perimetral en ningún bosque de Active Directory. Sin embargo, para mantener un marco de administración coherente, aplicar un conjunto común de directivas y ofrecer compatibilidad con inicio de sesión único, Microsoft IT implementa todos los servidores de transporte perimetral en un bosque de la extranet que es independiente del entorno de producción.

Por último, puede ver claramente que todos los mensajes de Internet llegan a Microsoft a través de los servidores de transporte perimetral situados en Norteamérica. Los servidores de transporte perimetral que se encuentran en Dublín y Singapur sólo atienden los mensajes salientes. La ventaja de concentrar todo el tráfico entrante en los servidores de transporte perimetral en Norteamérica es centralizar la seguridad y los controles contra correo electrónico no deseado mientras se evita la transferencia de mensajes salientes de los grandes centros de datos regionales a través de la red troncal de mensajería interna.

Omesh Desai, ingeniero de sistemas de Microsoft IT, diseñó la topología de transporte perimetral en Microsoft. Cuando pregunté a Omesh acerca de las características más importantes de diseño, me dijo: "En nuestro diseño de transporte perimetral, aprovechamos las capacidades nativas de Exchange contra el correo electrónico no deseado y las capacidades antivirus para conseguir una protección de mensajería en múltiples niveles en la red troncal de mensajería. La seguridad del perímetro de mensajería es la máxima prioridad pero también es importante un modelo de administración sencillo. Los servidores de transporte perimetral nos ayudan a aumentar la seguridad mediante configuraciones de firewall más estrictas a la vez que aumenta la precisión del filtrado de correo no deseado a través de servicios de reputación IP, actualizaciones automáticas de filtros de contenido, agregación de lista segura y validación de matasellos de correo electrónico. Toda la comunicación interna de servidor a servidor se cifra de forma predeterminada y si es posible ciframos también la comunicación con destinos externos.

En nuestros servidores de transporte perimetral usamos dos procesadores de doble núcleo de 64 bits y ocho gigabytes de memoria. Con seis de estos servidores, con equilibrio de carga a través de dos centros de datos, tenemos las capacidades necesarias para aguantar incluso grandes cargas de entregas de mensajes, tal como sucede durante los brotes de virus en Internet".

Laboratorio de pruebas de transporte perimetral

Instalación del laboratorio de pruebas

Dado que se recomienda usar nombres de dominio no existentes y direcciones IP privadas, usaré AdventureWorks.com y las direcciones IP de los intervalos 192.168.xxx.0-24. No hay matrices de sistemas redundantes ni de firewalls porque no realizo pruebas de equilibrio de carga ni tolerancia a errores. Por supuesto, los sistemas firewall actuales que usa Microsoft IT no se pueden analizar por razones de seguridad. De todos modos, dichos detalles no son importantes para este entorno de pruebas.

Mi entorno de pruebas usa ISA Server 2006 porque probablemente es uno de los sistemas firewall más comunes que se usan con Exchange Server 2007. La ejecución de ISA Server 2006 tanto en el firewall externo como en el interno ayuda a mantener la complejidad del entorno de pruebas en un nivel moderado, si bien para entornos de producción recomiendo usar sistemas variados de firewall externos e internos, para aumentar la seguridad. No implementé directivas de seguridad IP (IPsec) ni preparé el entorno para seguridad del nivel de transporte (TLS), porque estos temas están fuera del ámbito de este artículo.

Sin embargo, usé máquinas virtuales y software de evaluación de 32 bits, que puede descargar del sitio web de Microsoft. Microsoft no admite la versión de 32 bits de Exchange Server 2007 en producción, pero en un entorno de pruebas no presenta problemas.

Siempre que sea posible, mi laboratorio de pruebas depende de la configuración predeterminada. Sólo la configuración IP, los firewalls y las zonas DNS requieren cierta atención especial antes de ejecutar la instalación de Exchange Server 2007 y suscribir el servidor de transporte perimetral al entorno de producción. Para obtener más información respecto a la configuración IP, consulte el laboratorio de pruebas, en el archivo IP Configuration.xls que encontrará en la descarga complementaria. Si usa las mismas asignaciones de dirección IP, puede configurar rápidamente el firewall externo, llamado ISA01, si ejecuta directamente el script ISA01_Firewall_Policies.vbs en el equipo ISA01, y puede usar ISA02_Firewall_Policies.vbs para el firewall interno (ISA02). La descarga complementaria incluye también los archivos por lotes para configurar los servidores DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat y AD02_DNS_Config.bat). Debido a que estos archivos por lotes usan la herramienta de línea de comandos de DNS (dnscmd.exe), las herramientas de soporte de Windows deben estar instaladas; de lo contrario tendrá que crear manualmente los registros DNS por medio de la consola DNS.

Para evitar cualquier interferencia desde entornos existentes, mi laboratorio de pruebas no se conecta a Internet. Este aislamiento es una buena precaución. Aunque se generan errores en todas las descargas de actualizaciones de firmas, reputación de IP y filtros de contenido, esto no es crítico para fines de pruebas. Para evitar los mensajes de error, vaya a Actualizaciones del detector en la consola del Administrador de Forefront Server Security, y establezca la frecuencia de actualización de todos los motores de análisis en una vez, y especifique una fecha que ya haya pasado.

Para explorar estas características en acción, una buena práctica es construir un entorno de pruebas; el sentido común sugiere nunca usar un sistema de producción con fines de prueba. Como mínimo, necesita un servidor que ejecute Exchange Server 2007 para las funciones de servidor Buzón, Acceso de cliente y Concentrador de transporte. Necesitará un segundo Exchange Server para la función de servidor Transporte perimetral. Podría omitir la instalación del servidor de transporte perimetral si implementa todos los agentes de transporte en el servidor de funciones múltiples, si ejecuta el script Install-AntispamAgents.ps1 (lo podrá encontrar en los servidores concentradores de transporte en la carpeta %ProgramFiles%\Microsoft\Exchange Server\Scripts). Pero este enfoque se parecería poco a la implementación de Microsoft IT. Para un laboratorio de pruebas práctico, necesitará incluir algunos servidores más. La figura 2 muestra el entorno de pruebas que usé para la investigación de este artículo. En la descarga complementaria se encuentra a su disposición una ilustración más detallada. Para obtener más información acerca de la configuración del laboratorio, consulte la barra lateral "Instalación del laboratorio de pruebas".

Figura 2** Entorno de pruebas de transporte perimetral **(Hacer clic en la imagen para ampliarla)

Durante la suscripción del servidor de transporte perimetral y la configuración de los conectores asociados, Microsoft IT quita todos los conectores predeterminados y avanza con la creación de cuatro conectores para comunicarse eficientemente con los diferentes tipos de hosts SMTP (protocolo simple de transferencia de correo) y con los servidores concentradores de transporte internos. El primer conector de envío es un conector de Internet general para todos los destinos que no coinciden con definiciones específicas del espacio de direcciones.

El segundo conector de envío es un conector de Internet con definiciones detalladas del espacio de direcciones para destinos conocidos que no son compatibles con SMTP ampliado (dominios HELO). Mediante la configuración del parámetro ForceHELO para este conector en $true, Microsoft IT evita una secuencia innecesaria de EHLO, respuesta de error 500, HELO cuando se establecen conexiones SMTP.

El tercer conector de envío es un conector de Internet con definiciones detalladas del espacio de direcciones para dominios de asociados y otros dominios remotos compatibles con TLS para comunicarse de forma segura sobre conexiones cifradas (dominios TLS). El parámetro RequireTLS de este conector se establece en $true.

El cuarto conector de envío es un conector entrante para transferir los mensajes recibidos de Internet a los servidores concentradores de transporte en el entorno corporativo. Una vez más, para obtener información más detallada respecto a la configuración del servidor de transporte perimetral, consulte las notas del producto IT Showcase que se mencionan en la barra lateral "Recursos de Exchange".

Para aplicar una topología de conector del estilo de Microsoft IT al laboratorio de pruebas, usé un procedimiento basado en scripts creado por Omesh para uso interno de Microsoft IT. Por razones de seguridad, lo cambié y acorté drásticamente los comandos individuales, pero la topología del conector resultante todavía corresponde a la topología de Microsoft IT. Aquí tiene los pasos:

1. En el servidor Exchange de funciones múltiples (HUB-MBX-01) y el servidor de transporte perimetral (EDGE01), quitar los conectores predeterminados.
2. En HUB-MBX-01, crear un nuevo conector de recepción mediante la ejecución del script HUB-MBX-01_recv_connector.ps1 que se puede encontrar en la descarga de este artículo.
3. En EDGE01, crear dos nuevos conectores de recepción para la conectividad de mensajería interna y externa mediante la ejecución del script EDGE01_recv_connector.ps1.
4. En EDGE01, crear un archivo de suscripción mediante la ejecución de este comando:

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

Copiar el archivo de suscripción resultante a la carpeta raíz del servidor concentrador de transporte (c:\subscriptionfile.xml).

5. En HUB-MBX-01, asegurarse de que la ruta de acceso al archivo de suscripción es C:\subscriptionfile xml y, a continuación, ejecutar el script HUB-MBX-01_complete_subscription.ps1. Este script importa el archivo de suscripción para la sincronización perimetral sin la creación automática de un conector de envío, crea los conectores de envío para conectividad con Internet e interna, y replica la configuración resultante al servidor concentrador de transporte mediante la sincronización perimetral.

6. Compruebe la configuración mediante el envío de mensajes de prueba como Contoso.User@contoso.com y Fabrikam.User@fabrikam.com desde el host de Internet a Administrator@adventureworks.com y conteste a los mensajes recibidos para garantizar el funcionamiento de la transferencia de mensajes entrantes y salientes.

Sugiero que abra los archivos de script individuales en el Bloc de notas y analice los cmdlets y parámetros que usan estos scripts para realizar la configuración. La información detallada acerca de estos cmdlets y parámetros está disponible en línea en la documentación de producto de Exchange Server 2007.

Arquitectura de transporte perimetral

Ahora nos conectaremos con los agentes de transporte perimetral, que esperaban que alguien dijera HELO o EHLO desde el momento en que instalé la función de servidor de transporte perimetral. Si ejecuta el cmdlet Get-TransportAgent en el servidor de transporte perimetral, debe ver las 11 entradas que se enumeran en la figura 3. Todos los agentes están habilitados de forma predeterminada para ofrecer protección de mensajería con la configuración apropiada.

Figure 3 Agentes de transporte

El cmdlet Get-TransportAgent y la figura 3 enumeran los agentes por su orden de prioridad, aunque éste no es el orden en que los agentes realizan su trabajo. El orden del trabajo depende principalmente de la secuencia de eventos de recepción y eventos de enrutamiento SMTP para la que los agentes están registrados. Para ver cómo se relacionan los agentes y eventos, observe el diagrama que se muestra en la figura 4, que ilustra cómo se integran los agentes de transporte en la arquitectura de transporte perimetral.

Figura 4** Agentes de transporte dentro de la arquitectura de transporte perimetral. **(Hacer clic en la imagen para ampliarla)

Durante el procesamiento de los mensajes, los eventos de transporte ocurren en varias etapas intermedias para invocar código adicional para el filtrado de correo no deseado, realizar análisis de virus y otras tareas. En este diseño escasamente acoplado y extensible, el proceso de transporte perimetral (EdgeTransport.exe) asume la función de origen de eventos. Los controladores de eventos, en otras palabras los agentes de transporte, son objetos delegados administrados que se basan en Microsoft® .NET Framework 2.0, registrados con el origen de eventos para recibir notificaciones de devolución de llamada.

La figura 5 muestra los registros de evento de todos los agentes instalados en un servidor de transporte perimetral con Forefront Security. Es posible que estos registros sean algo difíciles de clasificar debido a la gran cantidad de registros de agente, pero no desespere. Si en un servidor de transporte perimetral ejecuta el comando Get-TransportPipeline | Format-List, puede analizar los registros de cada evento de transporte individual de manera más conveniente. Asegúrese de que el servicio de transporte de Microsoft Exchange (MSExchangeTransport.exe) se encuentra en ejecución y que ha enviado por lo menos un mensaje a través del servidor de transporte perimetral desde el último reinicio del servicio. Como revela la salida, se pueden registrar múltiples agentes para el mismo tipo de evento y se pueden registrar agentes individuales para múltiples eventos. Los registros de eventos sólo dependen de los requisitos de procesamiento del agente correspondiente.

Figura 5** Registros de evento de agentes de transporte **(Hacer clic en la imagen para ampliarla)

Uno de los eventos más importantes es el evento de enrutamiento OnSubmittedMessage, que se activa cuando un mensaje alcanza la cola de envío. Todos los mensajes deben pasar por esta cola a través de SMTP, ya sea que lleguen a través de SMTP, el sistema de archivos o por cualquier otro mecanismo. El categorizador es un componente principal de la arquitectura de transporte de Exchange Server, responsable de la resolución de destinatarios, bifurcación y enrutamiento de mensajes y generación de notificación del estado de entrega (DSN). El evento OnSubmittedMessage es por lo tanto una elección de registro perfecta para los agentes que deben procesar todos los mensajes recibidos. El agente de enrutamiento FSE es un componente de Forefront Security registrado para el evento OnSubmittedMessage para pasar todos los mensajes recibidos a los motores de análisis de virus. Debido a que el agente de enrutamiento FSE se registra para el evento OnSubmittedMessage, ningún mensaje puede saltarse la solución antivirus.

Así que ¿por qué simplemente todos los agentes no se registran para el evento OnSubmittedMessage y consideran realizado el trabajo? Porque desea bloquear los mensajes no deseados lo antes posible, antes de que su servidor confirme una entrega correcta. De lo contrario, sus servidores quizás tengan que procesar 90 millones de mensajes no deseados durante un ataque de correo no deseado o un virus, posiblemente tengan que generar 90 millones de informes de no entrega (NDR), lo cual puede suponer, a su vez, una amenaza grave para usuarios inocentes. Los ataques de correo no deseado y virus casi siempre usan información falsificada del remitente. El envío de millones de NDR a destinatarios que no crearon los mensajes originales no sólo representa un derroche de sus recursos y de los recursos de las organizaciones objetivo, también es una oportunidad para que usuarios malintencionados inunden el sistema con correo y realicen ataques DDoS. Por su propia protección y la de otros, es importante detener a los remitentes malintencionados en sus rastros.

Para bloquear de forma eficaz un mensaje, un agente de transporte debe interrumpir la conversación SMTP con el host remoto antes de que su servidor confirme la recepción de los datos con un código de estado 250 OK. Según el principio de almacenar y reenviar de SMTP, su servidor puede descartar sin riesgos cualquier dato recibido sin generar los NDR si no se ha confirmado la entrega del mensaje. Los agentes de recepción SMTP lo pueden realizar. Interactúan con la sesión SMTP porque la canalización de transporte invoca a estos agentes en función de eventos de recepción SMTP cuando el host remoto se conecta al servidor, establece una sesión SMTP, transmite los verbos SMTP, envía los mensajes y finaliza la conexión. Los eventos de recepción SMTP relacionados con cada paso se describen en la figura 6. Debido a la capacidad de rechazar los mensajes antes de la entrega y desconectar los hosts SMTP remotos, todos los agentes contra correo no deseado de Exchange Server 2007 se implementan como agentes de recepción SMTP.

Figure 6 Eventos de sesión SMTP

Es importante reconocer la diferencia entre agentes de recepción y agentes de enrutamiento SMTP con respecto a su contexto de procesamiento. Mientras que los agentes de enrutamiento tienen acceso completo a las propiedades del mensaje, los agentes de recepción SMTP son más sensibles al contexto porque interactúan con la sesión SMTP. Por ejemplo, un filtro de correo no deseado no puede actuar sobre las propiedades del mensaje hasta que el host remoto haya transferido el mensaje. Por lo tanto, es importante registrar al agente para el evento de recepción SMTP correcto. Consulte la barra lateral "Desarrollo de agentes de transporte" para obtener mayores detalles.

Recursos de Exchange

• Transporte perimetral y protección de mensajería en Microsoft Exchange Server 2007 (Notas técnicas de producto de Microsoft IT Showcase)
• Windows PowerShell Script Center
• Exchange Server 2007 TechCenter
• Blog del equipo de Microsoft Exchange "You Had Me From EHLO"

No deje de leernos

Tomemos un descanso antes de entrar con mayor detalle en la arquitectura de transporte y escenarios de prueba. He incluido mucha información, que abarca desde una implementación de servidores de transporte perimetral del estilo de Microsoft IT hasta los eventos internos que se activan en la canalización de transporte durante el procesamiento del mensaje. En la siguiente entrega de esta serie de dos partes, continuaré el análisis del comportamiento de los agentes de transporte perimetral en algunos escenarios de prueba interesantes.

Mientras tanto, le recomiendo descargar la versión de prueba de 90 días de Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) y seguir las explicaciones de Steve para compilar e instalar los agentes de ejemplo en su entorno de pruebas. Incluso si no es desarrollador, encontrará que es muy sencillo realizar estas tareas. No me sorprendería ver que un número creciente de aplicaciones de negocios dependa de agentes personalizados, dado lo útil que resulta desarrollar estos componentes en Exchange Server 2007 con Visual Studio 2005.

Kay Unkrothes una emprendedora que ha trabajado como ingeniera de soporte, desarrolladora de sistemas, consultora, instructora y autora especializada en tecnologías de servidores de Microsoft durante más de 15 años. Kay también es cofundadora y presidente de Biblioso Corporation, una compañía que se especializa en servicios administrados de documentación y localización.

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