Comunicaciones

Servidores Exchange de transporte perimetral en Microsoft: Segunda parte

Kay Unkroth

Resumen:

• Uso de registros y seguimientos en el transporte perimetral
• Configuración contra correo electrónico no deseado con scripts
• Pruebas en escenarios típicos de correo electrónico no deseado

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

Con la cantidad de correo electrónico no deseado y contenido malintencionado que circula por Internet, ¿cómo puede ofrecer mensajería confiable y segura a los usuarios de su organización? Una forma, que ya empecé a describir el mes pasado en la primera parte de esta serie, es implementar

servidores Exchange Server 2007 de transporte perimetral y Forefront Security para Exchange Server en una red perimetral entre Internet y su entorno de producción.

En esta entrega final, explicaré cómo analizar agentes de transporte perimetral en acción mediante funciones de registro y seguimiento estándar de Exchange Server 2007. También usaré un método personalizado para volcar todos los objetos de eventos de la canalización de transporte en archivos basados en XML. Después, ilustraré cómo aplicar configuración contra correo electrónico no deseado en un laboratorio de pruebas de transporte perimetral según la configuración que Microsoft usa en su propio entorno de producción corporativo. Por último, terminaré con algunos escenarios de prueba interesantes y realistas para ver cómo los agentes de transporte perimetral responden a varias situaciones de correo electrónico no deseado.

Para obtener más información sobre la instalación del laboratorio de pruebas de transporte perimetral y la arquitectura general de transporte perimetral, consulte el primer artículo de esta serie en el ejemplar de octubre de 2007 de TechNet Magazine, disponible en technetmagazine.com/issues/2007/10/Edge.

Hago un uso intensivo de scripts y archivos por lotes para automatizar las tareas de configuración más importantes. Puede encontrar estos scripts en la descarga de código que acompaña a este artículo (acuda a technetmagazine.com/code07.aspx). Además, para obtener información detallada de referencia sobre la configuración de TI de Microsoft respecto a los agentes de transporte perimetral, recomiendo las notas del producto "Transporte perimetral y protección de mensajería en Microsoft® Exchange Server 2007", producidas por Microsoft IT Showcase. Puede descargar estas notas del producto de IT Showcase en microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Registro y seguimiento

Exchange Server 2007 incluye varias funciones de registro y seguimiento, entre ellas, registro de protocolos, registro de agentes y seguimiento de la canalización, que facilitan el diagnóstico y la solución de problemas de agentes de transporte. Aunque en este artículo no me voy a ocupar exactamente de la solución de problemas de agentes de transporte, la información de registro y seguimiento es útil para examinar cómo funcionan los agentes de transporte perimetral.

Si quiere realizar un seguimiento de información acerca de actividades SMTP de envío y recepción, debería habilitar el registro de protocolos para los conectores de envío y recepción. Con el entorno de pruebas que configuré en la primera parte de esta serie (consulte la figura 1), habilité el registro de protocolos por medio del parámetro siguiente en los cmdlet New-SendConnector y New-ReceiveConnector:

Figura 1** El entorno de pruebas **

–ProtocolLoggingLevel: Verbose

Puede encontrar los archivos de registro SMTP resultantes de forma predeterminada en subcarpetas bajo %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.

El registro de protocolos es útil si quiere analizar conversaciones SMTP, aunque los agentes contra correo electrónico no deseado no siempre interfieren con la sesión SMTP. Por ejemplo, el agente de filtro de contenido quizás sólo marque los mensajes entrantes con un valor de nivel de confianza contra correo no deseado (SCL). Mientras que el valor SCL esté por debajo de un umbral especificado (el valor predeterminado es 7), el agente de filtro de contenido no hará que el proceso de transporte perimetral rechace el mensaje. Por lo tanto, los progresos de conversación SMTP no resultan afectados.

Para analizar las acciones que los agentes contra correo electrónico no deseado (filtro de conexión, filtro de contenido, reglas perimetrales, filtro de destinatarios, filtro de remitentes e identificador de remitente) realizan en los mensajes que pasan por la canalización de transporte, necesita comprobar los registros de agentes en vez de los registros de protocolos. El registro de agentes se suele habilitar según el parámetro AgentLogEnabled en el archivo EdgeTransport.exe.config. De forma predeterminada, los registros de agentes se encuentran en la carpeta %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Puede abrir los registros en Bloc de notas, aunque el cmdlet Get-AgentLog muestra la información de registro de agentes de forma más intuitiva en el Shell de administración de Exchange.

Otra función útil es el seguimiento de la canalización, que permite capturar instantáneas de mensajes de un remitente particular según los mensajes van pasando por la canalización de transporte. La idea es relativamente sencilla; el proceso de transporte perimetral crea una instantánea de cada mensaje antes y después de invocar agentes de enrutamiento y recepción SMTP registrados para los eventos OnEndOfHeaders, OnEndofData, OnSubmittedMessage y OnRoutedMessage. Al comparar las instantáneas de mensajes, puede ver cómo los agentes individuales modifican cada mensaje. Por supuesto, es imprescindible que habilite esta valiosa función en el entorno de pruebas.

El uso siguiente del cmdlet Set-TransportServer activa el seguimiento de canalización para un usuario de prueba. El parámetro PipelineTracingEnable establecido en $true habilita el seguimiento de la canalización. La dirección de correo electrónico del usuario de prueba se establece en el parámetro PipelineTracingSenderAddress:

Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com

Con el seguimiento de canalización habilitado, puede encontrar archivos de instantáneas para cada mensaje del remitente especificado (en este caso, Contoso.User@contoso.com) en la carpeta %ArchivosDePrograma\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Esta es la carpeta predeterminada. Para cada mensaje, los archivos de instantáneas se encuentran en un subdirectorio nombrado según un GUID asignado al mensaje. Tenga en cuenta que puede encontrar el mensaje original en un archivo llamado Original.eml y copias del mensaje en archivos .eml que empiezan con SmtpReceive o Routing según los eventos encontrados y los agentes instalados. Para analizar el procesamiento de agentes contra correo electrónico no deseado registrados para los eventos de recepción SMTP OnEndofData y OnEndOfHeaders, compruebe los archivos .eml SmtpReceive*. Para analizar el procesamiento de antivirus y otros agentes registrados para los eventos de enrutamiento OnSubmittedMessage y OnRoutedMessage, analice los archivos .eml Routing*.

Volcado de canalización personalizado

Las funciones de registro y seguimiento de agente estándar de Exchange Server 2007 satisfacen todas las necesidades de solución de problemas a pesar de que las funciones estándar no cubren todos los eventos de transporte. Por ejemplo, el seguimiento de canalización no puede capturar información acerca de OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand ni de eventos de transporte semejantes, porque el host de envío aún no ha transferido ningún mensaje que podría escribirse en la carpeta %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Si desea capturar información detallada acerca de estos eventos, necesita implementar un agente personalizado que vuelque los datos de evento en archivos del sistema de archivos.

Como vimos en mi artículo anterior, no es complicado crear agentes personalizados, así que no he podido resistir la tentación de crear un agente de recepción SMTP y un agente de enrutamiento para volcar todos los objetos de evento de la canalización de transporte en archivos XML. Encontrará un proyecto correspondiente de Microsoft Visual Studio® 2005 llamado PipelineXMLDump en la descarga disponible para este artículo. Los dos archivos importantes son DumpAgents.cs, que implementa las fábricas de agente y los agentes, y XMLDump.cs, que implementa una clase auxiliar para escribir los campos de objetos de origen y argumento de eventos por medio de métodos System.Re- flection en archivos XML. Si compila el código fuente y copia el archivo PipelineXMLDump.dll resultante en una carpeta llamada C:\PipelineXMLDump en el servidor de prueba de transporte perimetral, puede registrar y habilitar los agentes personalizados con los scripts RegisterPipelineXMLDump.ps1 y EnableDumpAgents.ps1. Los scripts están incluidos en la carpeta de proyecto PipelineXMLDump de la descarga. Por supuesto, mis agentes personalizados tienen únicamente propósitos ilustrativos, no se han probado lo suficiente y no se deben instalar nunca en un servidor de producción. La responsabilidad del uso de estos agentes queda por entero con el usuario.

DumpAgents.cs muestra cómo implementar todos los controladores de eventos de enrutamiento y recepción SMTP compatibles con la canalización de transporte. Este puede ser un buen punto de partida si quiere implementar sus propios agentes personalizados. Mis agentes de volcado escriben archivos XML en subcarpetas bajo %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump que corresponden al identificador de la sesión SMTP (agente de recepción SMTP) o al identificador del mensaje (agente de enrutamiento). La figura 2 presenta un ejemplo de información de argumento de eventos transmitida al agente de recepción SMTP en el controlador OnConnectEvent. El ejemplo revela el extremo IP local (puerto y dirección IP) que aceptó una solicitud de conexión entrante.

Figura 2** Información del argumento volcada durante el evento OnConnect **(Hacer clic en la imagen para ampliarla)

Preparación de las pruebas

Ya hemos visto suficiente teoría acerca del registro, el seguimiento y el volcado. Preparémonos para la ejecución de algunas pruebas que muestran agentes contra correo electrónico no deseado en acción. El siguiente es un resumen breve que refleja la configuración de TI de Microsoft de la forma más precisa posible en su entorno de pruebas. Como mencioné anteriormente, hay información de referencia disponible en las notas del producto "Transporte perimetral y protección de mensajería en Microsoft Exchange Server 2007".

Empiece por desactivar el agente de reescritura de direcciones de la bandeja de entrada, el agente de filtro de datos adjuntos y el agente de reescritura de direcciones de la bandeja de salida mediante la ejecución del script EDGE01_disable_agents.ps1 de la descarga. La reescritura de direcciones no es necesaria, porque los destinatarios usan las mismas direcciones de correo electrónico interna y externamente. No uso el agente de filtro de datos adjuntos porque hay funciones de filtrado de datos adjuntos superiores en Forefront Security.

El entorno de pruebas no está conectado a Internet. Esto dificulta la comprobación del agente de filtro de conexión. Para remediar el problema, puede crear una lista de direcciones IP bloqueadas en el host de Internet mediante la ejecución del archivo INTERNET01_create_IP_block_list.bat. Asegúrese de que tiene instaladas las herramientas de soporte de Windows®, ya que incluyen la herramienta de línea de comandos DNS (dnscmd.exe). De lo contrario, tendrá que emplear tiempo creando los registros DNS manualmente con la consola DNS.

Ahora puede configurar el agente de filtro de conexión mediante la ejecución del script EDGE01_add_block_list_provider.ps1. Este script agrega un proveedor de la lista de direcciones IP bloqueadas para ip-bl.consolidatedmessenger.com. Esta es la lista de direcciones IP bloqueadas de Consolidated Messenger, ya creado en el entorno de pruebas con la ejecución del archivo INTERNET01_create_IP_block_list.bat en el host de Internet, como mencionamos anteriormente. La configuración de TI de Microsoft usa también la lista de direcciones IP bloqueadas y la lista de direcciones IP permitidas, pero estas funciones no requieren configuración manual. Es importante tener en cuenta que la configuración de TI de Microsoft no usa proveedores de la lista de direcciones IP permitidas.

A continuación, configure el agente de filtro de destinatarios mediante la ejecución del script EDGE01_recipient_filter.ps1 para bloquear mensajes a destinatarios inexistentes, así como mensajes a buzones y listas de distribución global que son sólo para uso interno o de salida.

El agente de filtro de remitentes necesita también una actualización de la configuración. La configuración de TI de Microsoft usa filtrado de remitentes como medida contra ataques de inundación de correo desde direcciones de remitente específicas y para bloquear ciertos servidores de la lista y orígenes semejantes que no se consideran relevantes para el negocio. Además, la configuración de TI de Microsoft usa filtrado de remitentes para bloquear mensajes con información de remitente no válida o ausente. Apliquemos esta configuración al entorno de pruebas con la ejecución del script EDGE01_sender_filter.ps1 en el servidor del transporte perimetral.

Necesita también configurar registros de marco de directivas de remitente (SPF) en DNS, si quiere reflejar la configuración de TI de Microsoft. Para generar un registro SPF que confirme la autoridad de su servidor de transporte perimetral para mensajes de su dominio, adventure-works.com, puede usar el Asistente para el registro SPF de identificador de remitentes de Microsoft disponible en microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Pruébelo y especifique un nombre de dominio de Internet existente. En el entorno de pruebas, puede ejecutar el archivo INTERNET01_create_SPF_record.bat en el host de Internet.

Ya está. No hace falta configurar parámetros adicionales, porque la mayor parte de los agentes incluyen una configuración predeterminada razonable. Para realizar una comprobación rápida de la configuración predeterminada más importante para los agentes de reglas perimetrales, identificador de remitente, análisis de protocolo y filtro de contenido, ejecute el script EDGE01_check_defaults.ps1 en el servidor de transporte perimetral.

Agentes de transporte perimetral en acción

Ahora, pongamos los agentes de transporte perimetral a trabajar en algunos escenarios realistas de mensajería. Para enviar mensajes de prueba al servidor de transporte perimetral, uso el servicio POP3 y SMTP incluido en Windows Server 2003 y Outlook® Express como cliente de mensajería, con la configuración predeterminada gran parte del tiempo, pero con el registro habilitado.

Pero primero, una advertencia: no siga ninguno de estos pasos ni ejecute los scripts descritos en esta sección si su entorno de pruebas tiene alguna conexión a sistemas de producción o a Internet. Una vez más, la responsabilidad es suya.

El primer agente que voy a probar es el agente de filtro de conexión. Merece ser el primero, porque es el agente que trabaja más duro en un servidor de transporte perimetral. En Microsoft, el agente de filtro de conexión bloquea aproximadamente el 88 por ciento de todos los envíos de mensajes de Internet. De 13 millones de intentos de envío en un día normal, sólo alrededor de 1,5 millones son de remitentes legítimos.

Así que enviemos un mensaje de correo electrónico como Fabrikam.User@Fabrikam.com a Administrator@adventure-works.com. Si las cosas funcionan apropiadamente, el administrador no recibirá el mensaje. En su lugar, Fabrikam.User recibirá una notificación de estado de entrega (DSN) para indicar que la entrega no se ha realizado. Fabrikam.User comprueba que la dirección de correo electrónico es correcta, envía de nuevo el mensaje y, una vez más, Fabrikam.User recibe una DSN. Entonces, Fabrikam.User se pone en contacto con el departamento de soporte técnico y notifica el problema. No es el primer usuario que tiene este problema. De hecho, ningún usuario de Fabrikam se puede comunicar con Adventure Works. Algo ha sucedido. El problema es urgente. Para resolverlo rápidamente, compruebe los registros SMTP en la carpeta %systemroot%\system32\Logfiles\SMTPSVC1 de INTERNET01 y, como muestra el texto rojo en la figura 3, ahí está.

Figure 3 Los registros SMTP muestran el problema.

... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu, 
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by 
ip-bl.consolidatedmessenger.com. Please visit 
http://www.consolidatedmessenger.com/ip-bl for more information. 
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,

El error 550 indica que Consolidated Messenger puso la dirección IP de su host de Internet en una lista de direcciones IP bloqueadas. Bueno. Entonces, se pone en contacto con Consolidated Messenger para que modifiquen la lista. Pero resulta que es más fácil entrar en la lista de direcciones IP bloqueadas de Consolidated Messenger que salir. Se tardará días, si no semanas, en solucionar el problema.

Necesita ayuda más rápidamente, así que se pone en contacto con Adventure Works a través de la dirección de correo electrónico cmipbl@adventure-works.com. Envía un mensaje de correo electrónico como Fabrikam.Admin@Fabrikam.com, describe la situación y solicita el desbloqueo de la dirección IP de Internet de su host (en este caso, 192.168.1.100). Después de comprobar su identidad, Adventure Works desbloquea la dirección mediante el uso del comando siguiente para conceder una excepción temporal que expira automáticamente a los 30 días:

Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)

Treinta días deberían ser suficientes para arreglar las cosas con Consolidated Messenger, y Adventure Works no necesita emplear tiempo en el mantenimiento manual de la excepción. Al conceder excepciones de expiración automática, Adventure Works conserva al mínimo la carga administrativa asociada con el mantenimiento de listas de direcciones IP permitidas.

Remitentes seguros

Ahora, probemos el reconocimiento de remitentes seguros del filtrado de contenido, una función nueva e interesante que aumenta la precisión del filtrado de correo electrónico no deseado. EdgeSync propaga información de remitentes seguros del entorno interno en formato con hash y cifrado a los servidores de transporte perimetral. El agente de filtro de contenido usa esta información durante el proceso de filtrado para tomar decisiones con fundamento. Sólo necesita obtener la información de remitentes seguros (es decir, la lista de remitentes seguros, la lista de destinatarios seguros, la lista de remitentes bloqueados y los contactos externos) en Active Directory® con el cmdlet Update-SafeList y la réplica de la información al servidor de transporte perimetral mediante el cmdlet Start-EdgeSynchronization. El departamento de TI de Microsoft ejecuta el cmdlet Update-SafeList con una frecuencia programada fuera de horas punta. En nuestro entorno de pruebas, es suficiente ejecutar un script correspondiente (HUB-MBX-01_update_safelist.ps1) de forma manual.

Primero, preparemos el entorno de pruebas con la ejecución del script EDGE01_clean_up.ps1 en el servidor de transporte perimetral para quitar la entrada de la lista de direcciones IP permitidas creada anteriormente. Esto es necesario porque el agente de filtro de contenido no se aplica a mensajes de orígenes que están en esta lista. A continuación, quite la entrada de la lista de direcciones IP bloqueadas correspondiente a 100.1.168.192.ip-bl.consolidatedmessenger.com de la lista de bloqueo de Consolidated Messenger mediante la ejecución del archivo INTERNET01_clean_up.bat en el host de Internet. De otro modo, el host simulado de Internet no podrá enviar los mensajes, como ya demostramos.

Finalmente, envíe un mensaje que el agente de filtro de contenido seguramente considerará correo no deseado. Esto es complicado, porque el agente de filtro de contenido usa el umbral de rechazo SCL predeterminado para entregar la mayoría de los mensajes a los usuarios y reducir al mínimo falsos positivos. Sin embargo, después de algunas pruebas, encontré un mensaje que incrementa la clasificación de SCL hasta el nivel de rechazo. Para enviar el mensaje como Contoso.User@Contoso.com, ejecute el script INTERNET01_contoso_msg.vbs en el host de Internet.

Mi script usa una conexión SMTP anónima para enviar el mensaje al servicio SMTP en INTERNET01. Para que funcione, necesita configurar el servicio SMTP para retransmitir mensajes a usuarios anónimos. En Administrador de IIS, abra las propiedades para el servidor virtual SMTP predeterminado. En la ficha Acceso, haga clic en el botón Retransmisión y seleccione Todo menos la lista siguiente. Hablaré de las implicaciones de esta configuración en un momento.

Cuando ejecute el script para enviar este mensaje, Contoso.User recibirá una DSN que indica que la entrega produjo un error con el código de diagnóstico: smtp;550 5.7.1, correspondiente a mensajes rechazados por restricciones de contenido. También puede ver esta respuesta en el registro SMTP del host de Internet, y si ejecuta el comando Get-AgentLog | Select-Object -Last 1 en el servidor de transporte perimetral para mostrar la última entrada del registro de agentes, podrá ver que el mensaje se rechazó porque su clasificación de SCL era 7, como muestra la figura 4.

Figura 4** Mensaje bloqueado debido a restricciones de contenido **(Hacer clic en la imagen para ampliarla)

Ahora, Contoso.User no es remitente de correo no deseado. Es lamentable que su mensaje no se aceptara en este caso, pero Contoso.User se puede comunicar generalmente con destinatarios en Adventure Works. Así que Contoso.User informa al administrador en otro mensaje de correo electrónico que su mensaje original se bloqueó por error. El administrador conoce a Contoso.User y, para garantizar que los filtros de correo no deseado no bloquean sus mensajes en el futuro, el administrador incluye a Contoso.User en la lista de remitentes seguros. Para hacer esto en Office Outlook 2007, haga clic con el botón secundario en un mensaje recibido de Contoso.User, seleccione Correo electrónico no deseado y haga clic en Agregar el remitente a la lista de remitentes seguros.

Con el intervalo usual, el cmdlet Update-SafeList se ejecuta para actualizar la información de la lista de remitentes seguros en Active Directory y, después de la sincronización perimetral siguiente, Contoso.User se podrá comunicar con el administrador sin falsos positivos. Para simular este procedimiento, ejecute el script HUB-MBX-01_update_safelist.ps1.

Ahora ejecute el script INTERNET01_contoso_msg.vbs para enviar el mensaje de Contoso.User otra vez. Compruebe después el registro de agentes en el servidor de transporte perimetral con el comando Get-AgentLog | Select-Object -Last 1 y, bajo ReasonData, podrá ver que el filtrado de contenido quedó eludido. Se acabaron los falsos positivos para Contoso.User.

Ataques de correo electrónico no deseado

Para concluir las pruebas, tirémoslo todo por la borda. Como sin duda habrá advertido, configuré el host de Internet durante la prueba anterior como relé abierto, que abre la puerta a remitentes de correo no deseado. Así que ahora veamos lo que sucede si Spam.Sender@cohovineyards.com advierte esta configuración deficiente y abusa del host para enviar miles de mensajes de correo no deseado a Adventure Works. El script INTERNET01_spam_msg.vbs sólo envía un mensaje de correo no deseado, pero puede editar el script y cambiar el valor max_loop para generar más.

Para simular un ataque de correo no deseado, envié 1.000 mensajes a mi host para la transmisión al servidor de transporte perimetral. El servicio SMTP limita el número de mensajes por conexión de salida a 20, así que llevó algún tiempo transmitir un número suficiente de mensajes de correo no deseado para que el agente de análisis de protocolo del servidor de transporte perimetral entrara en acción.

El agente de análisis de protocolo ayuda al agente de filtro de conexión con el mantenimiento automático de las entradas de la lista de direcciones IP bloqueadas en base al análisis de protocolo SMTP y a las actualizaciones de reputación IP de Microsoft Update. En este caso, el análisis del protocolo SMTP atrapó los mensajes de correo electrónico no deseado. El agente de análisis de protocolo realiza un seguimiento de la clasificación de SCL de cada mensaje para calcular un valor SCL medio que usa para determinar el nivel de reputación de un remitente (SRL). Según iban llegando cada vez más mensajes ilegítimos durante mi campaña simulada de correo no deseado, el SRL del host de Internet fue aumentando hasta superar el umbral de bloqueo SRL. Como resultado, el host acabó en la lista de direcciones IP bloqueadas durante 24 horas. Se acabó el correo electrónico no deseado de este host. Sucedió automáticamente. No fue necesaria la intervención del administrador.

La figura 5 muestra la entrada resultante de la lista de direcciones IP bloqueadas y los cambios correspondientes en el tratamiento de los mensajes. Antes del bloqueo del host, el servidor de transporte perimetral rechazaba cada mensaje de correo no deseado durante el evento OnEndOfData porque el agente de filtro de contenido respondía a cada mensaje según el umbral de SCL (vea la figura 4 como referencia). El mensaje se envió, pero no se entregó correctamente. Tras el bloqueo del host, la conexión quedó rechazada durante el evento OnMailCommand por parte del agente de filtro de conexión. Los mensajes ya no se envían. Ahorra ancho de banda de la red y recursos de procesamiento para desconectar a remitentes de correo no deseado antes de la entrega de los mensajes.

Figura 5** Bloqueo de un host de Internet remitente de correo no deseado **(Hacer clic en la imagen para ampliarla)

Más pruebas

Por supuesto, hay más funciones y escenarios de agentes que puede probar. Por ejemplo, puede probar el filtrado de remitentes mediante el envío de mensajes como Blocked.User@Contoso.com o Blocked.User@Fabrikam.com. Puede probar el filtrado de destinatarios mediante el envío de mensajes a Blocked.User@adventure-works.com. También puede usar Telnet para simular ataques de recolección de directorios con intervalos de retraso diferentes. La configuración de TI de Microsoft usa el intervalo predeterminado de cinco segundos para respuestas 5yz de SMTP en el conector de recepción de cara a Internet, tiempo suficiente para que el departamento de TI de Microsoft pueda convertir los intentos de recolección de directorios en ataques frustrados. Pero puede aplicar valores diferentes con el cmdlet Set-ReceiveConnector, como demuestra el script EDGE01_tarpitting.ps1.

Puede ir más allá y consultar los archivos de instantáneas creados por el seguimiento de canalización para los mensajes de Contoso.User@Contoso.com. Compruebe las marcas antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, que Forefront Security usa para marcar los mensajes según se examinan. Cuando Forefront Security en el servidor de transporte de concentradores encuentra esta marca con información de versión reciente, no tiene que examinar el mensaje una segunda vez. Si trata de eludir Forefront Security al insertar marcas antivirus falsas en sus mensajes de prueba, verá el firewall de encabezados en acción: quitará estas marcas justo después del evento OnDataCommand, mucho antes de que se active el evento OnSubmittedMessage que invoca al agente de enrutamiento de FSE.

Mientras consulta los encabezados de mensajes en los archivos de instantáneas, quizás desee crear un registro de prueba SPF para Contoso.com que identifique una dirección IP incorrecta como remitente legítimo. Una forma de conseguirlo es ejecutar el archivo INTERNET01_wrong_SPF_record.bat en el host de Internet. Después, debería enviar un mensaje de prueba como Contoso.User@Contoso.com y examinar los encabezados X-MS-Exchange-Organization-SenderIdResult y Received-SPF:

X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusión

Como ha visto en este artículo y en el anterior, los servidores de transporte perimetral de Exchange Server 2007 vienen con un conjunto completo de agentes de transporte para implementar funciones contra correo electrónico no deseado confiables y de gran precisión, entre ellas, filtrado de conexión, análisis de protocolo y filtrado de contenido. La arquitectura de transporte es extensible y compatible con la implementación de agentes adicionales para obtener funcionalidad ampliada. El agente de enrutamiento FSE es un buen ejemplo de un agente adicional que integra Forefront Security para Exchange Server en la arquitectura de transporte.

En combinación con funciones adicionales, por ejemplo, retraso de la conexión, firewall de encabezados, TLS y autenticación, los servidores de transporte perimetral ofrecen los medios necesarios para lograr un nivel muy alto de protección de la mensajería en múltiples niveles y sin puntos únicos de posibles errores. Con la implementación de servidores de transporte perimetral y Forefront Security en una red perimetral, de forma estrictamente independiente de su organización interna del servidor Exchange, puede mantener el contenido malintencionado e ilegítimo lejos de su entorno de mensajería al tiempo que realiza la entrega de mensajes legítimos a los usuarios con tasas de falsos positivos muy bajas.

Kay Unkrothes una empresaria 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.