DMZ y servidores de correo

La teoría es que el tráfico a la DMZ debe ser entrante . En ese caso, si algo malo le sucediera al host de DMZ, el ataque está contenido dentro de la DMZ.

Esto significa que las conexiones desde su LAN deben iniciarse en la LAN, lo que generalmente significa algún tipo de operaciones push (a la DMZ) o pull (de la DMZ). Esto es factible para el correo, pero a veces es impracticable para otros servicios.

En ese caso, la DMZ se ve a menudo como una "capa delgada" que, en teoría, es más robusta (porque es más liviana) y, por lo tanto, potencialmente menos propensa a las vulnerabilidades (y piratea).

Esto es particularmente cierto cuando obtiene los datos reales de un servicio gigantesco al que no se debe acceder directamente. Esta capa adicional también le permite " romper el protocolo "(como mencionó), lo que significa que un ataque que habría tenido éxito en el host objetivo no será factible en el expuesto (debido al cambio arquitectónico que detiene la carga útil en la primera capa (que no es vulnerable a ese ataque)).

Hay dos aspectos de la seguridad del correo electrónico w.r.t. la DMZ:

1. Transporte SMTP (entrante)
2. conectividad del cliente

El transporte SMTP requiere exploración AV y, a menudo, requiere búsquedas de DNS, protección de virus, etc. Si el procesamiento SMTP se subcontrata a Google, Microsoft, Proofpoint, no veo ningún problema para permitir que se transmita directamente, como lo está el tercero. el DMZ subcontratado.

Para la conectividad del cliente, la mayoría de los balanceadores de carga que he visto requieren que POP3, IMAP, HTTP, RPC / HTTPS de destino residan en la misma subred que la interfaz del balanceador de carga. Además, los análisis pueden verse afectados dependiendo de si el equilibrador de carga es la puerta de enlace / enrutador para cada servidor (el servidor verá el GatewayIP en lugar de la IP del cliente).

Solo puedo hablar con las implementaciones de Microsoft, ya que esa es mi experiencia. Microsoft no admite la colocación de un firewall entre los servidores front-end y back-end. Solían hacerlo en 2003 y antes, pero este ya no es el caso.

Mi sugerencia es instalar Microsoft Office Server en la DMZ para la representación web de datos de correo electrónico y desactivar WebReady procesamiento en el servidor de Exchange en la LAN.

Los documentos listos para la Web son el único riesgo que puedo decir que existe en la plataforma de Microsoft