LAS MEJORES PRÃCTICAS | DNSBL y el filtrado de correo electrónico: cómo hacerlo correctamente

Filtrado eficiente y eficaz

Existen muchas opciones de seguridad de correo electrónico para tu infraestructura: desde filtrado y escaneo de contenido hasta herramientas basadas en la red que usan métodos distribuidos y colaborativos.

Desafortunadamente, casi todo lo anterior es costoso y requiere muchos recursos.   La clave del filtrado de correos electrónicos es eliminar el grueso de correos no deseados desde el principio del proceso, antes de que lleguen a la etapa de inspección de contenido que sí requiere muchos recursos.

La comprobación DNSBL es el método más sencillo, rápido y económico que tienes a tu disposición. Entonces, ¿por qué no utilizarlo?

Etapas para usar las DNSBL

Cuando aceptas y procesas un correo electrónico, hay tres áreas en las que debes usar blocklists:

1. En la conexión inicial, cotejando la IP que se conecta.
2. A lo largo de la fase previa a los datos de un correo electrónico;es decir, la transacción SMTP
3. Una vez aceptados los datos del correo; es decir, durante la inspección de contenido

Beneficios de usar las DNSBL antes del filtrado de contenido

• Ahorra ancho de banda: reducirás significativamente la cantidad de mensajes que se tienen que descargar.
• Ahorra conexiones abiertas: muchas conexiones no se mantienen abiertas innecesariamente.
• Ahorra actividad de almacenamiento: el rechazo antes del filtrado de contenido no utiliza recursos de almacenamiento (a excepción de algunas líneas de la bitácora).
• Reducción general de los requisitos de memoria, almacenamiento y CPU: tienes un volumen mucho menor de correos que requieren el costoso escaneo de contenidos.

1. El uso de las blocklists de DNS en la conexión inicial del correo electrónico

Al principio de una transacción de correo electrónico, un servidor remoto intenta iniciar una conexión con tu servidor.   En este punto, una búsqueda rápida (consulta) en una blocklist puede informar instantáneamente (bueno, casi al instante) si la dirección IP que se conecta está asociada, o no, con un comportamiento malicioso.

Si la dirección IP está en la lista, puedes elegir abandonar la conexión de inmediato.   Recuerda, esta consulta se realiza incluso antes de que ocurra el intercambio de señales del Protocolo para transferencia simple de correo (SMTP).

Qué blocklists se deben utilizar:

• Blocklist de Spamhaus (SBL)
• Blocklist de exploits (XBL)
• Blocklist de políticas (PBL)

2. El uso de las blocklists de DNS durante la fase previa a los datos

¿Qué es la fase previa a los datos?

Para todos los comandos de correo electrónico que ocurren después del establecimiento de la conexión de correo electrónico inicial (como se explicó anteriormente) y antes del comando DATA durante la conexión SMTP, estamos hablando de la fase previa a los datos.

Comprueba el DNS inverso de la IP que se conecta

Una vez abierta la conexión, tú (el destinatario) debes hacer una búsqueda de DNS inverso de la dirección IP que se conecta.

¿El resultado de la comprobación rDNS coincide con la cadena HELO?

El resultado de la búsqueda anterior debería consultarse con el dominio contenido en la cadena HELO del remitente; p. ej.: (HELO mta-out.someisp.example). Si no coinciden, la conexión deberá abandonarse de inmediato.   Este es un indicador de que el remitente no es quien dice ser; p. ej., suplantación.

Consulta el resultado de la rDNS en las blocklists

Consulta el dominio devuelto en la DBL y el ZRD.

Consulta en las blocklists el dominio contenido en la cadena HELO

El dominio contenido en la cadena HELO deberá consultarse en la DBL y el ZRD al mismo tiempo que se ejecuta una búsqueda de DNS adelantada en la SBL.

Consulta el dominio MAIL FROM (Ruta de retorno)

Después de la cadena HELO, durante la conexión SMTP, está el comando MAIL FROM.   Este se conoce normalmente como “Envelope-from” o “Return-path”. Debes consultar el dominio que viene en esta cadena; p.ej., <[email protected]>

Cuando se consulta en la DBL y el ZRD y se recibe una respuesta positiva, los destinatarios pueden rechazar el correo o etiquetarlo para inspeccionarlo más a fondo durante el proceso de filtrado de contenido.

La transferencia del encabezado y del contenido del correo electrónico

Una vez ejecutado el comando RCPT TO, sigue el comando DATA, y este es el que inicia la transferencia de datos, tanto del encabezado como del contenido del correo electrónico. Cuando el destinatario confirma que se ejecutó correctamente, el remitente transmite un comando QUIT, antes o después de la inspección de contenido, y se cierra la conexión.

¿Se mantiene abierta la conexión durante la inspección de contenidos?

Esto depende de tus decisiones durante la implementación y el software elegido.   Al igual que con todas las opciones, hay puntos a favor y en contra para ambas:

Algunas implementaciones eligen mantener la conexión abierta hasta obtener el resultado de la inspección de contenidos.

Puntos a favor: Los remitentes siempre serán notificados de un rechazo, que es la mejor estrategia en el caso de que se presenten falsos positivos.

Puntos en contra: Consume muchos recursos y tu MTA debe estar a la altura de la tarea, incluso durante los picos. Cuando escasean los recursos, podría haber retrasos.

La mayoría de las implementaciones cierran la conexión antes de la inspección de contenido.

Puntos a favor: Costos más bajos debido a que los requerimientos de recursos son menores.

Puntos en contra: No se avisará al remitente los casos de falsos positivos.

Una inmersión profunda en los beneficios de utilizar DNSBL antes del filtrado de contenido

Reducción de la carga de tus recursos

Como se dijo anteriormente, el filtrado de contenido y el escaneo demandan abundantes recursos. Reducir la cantidad de correos que llegan a este punto del proceso de filtrado de correos electrónicos ahorra memoria, reduce la potencia de procesamiento y disminuye la latencia.

Protección de la infraestructura contra campañas de spam

Piensa en una situación en la que recibes cientos de mensajes por segundo durante una campaña sostenida o creciente de spam.   Si dependes del filtrado de contenido o del escaneo para mitigar el ataque, tu infraestructura de correo electrónico podría colapsar simplemente por la carga del volumen de correos entrantes.

Aún si tienes la suerte de que esto no suceda, seguirás incurriendo en altos costos, puesto que cada correo debe ser descargado y escaneado.

Los remitentes pueden depurar los problemas de retransmisión de correo

Cuando un correo se rechaza en la conexión inicial o en el saludo SMTP, se envía al remitente una notificación del estado de la entrega (DSN) en tiempo real para avisar de la entrega fallida.   Desde la perspectiva del remitente, esto podría ayudar a identificar y resolver los problemas de retransmisión de correos.

Los correos electrónicos no se quedan en las carpetas de correo no deseado

Como resultado de que los correos se rechacen en las primeras etapas de la transacción de correos electrónicos, los posibles correos electrónicos de spam no se descargan ni se dejan olvidados en una carpeta de correo electrónico no deseado.   De esta manera se evita que los usuarios finales busquen un correo legítimo entre los cientos o miles de correos de spam en la carpeta de correo no deseado.

La infraestructura de terceros inocentes no se inunda con correos devueltos

Si la dirección del remitente es una dirección falsificada, el tercero inocente, cuyo correo se falsificó, se inundará de mensajes devueltos.

Mayor protección contra campañas de spam tormenta y spam snowshoe

El uso de blocklists de dominio así como blocklists de IP te ofrece protección adicional contra spam tormenta y spam snowshoe, además de otras amenazas. Para conocer este tema con más detalle, te sugerimos leer Desarrolladores MTA: permitan el uso de DNSBL de dominio a nivel de SMTP.

¡Vale la pena recordar que nuestra blocklist de dominio contendrá muchos dominios antes de que los vea el público en general!

3. El uso de las blocklists de DNS durante la fase posterior a los datos

Cuando ya se ejecutó el comando DATA y el encabezado y el contenido del correo se transmitieron al destinatario, empieza la inspección de contenido, junto con las comprobaciones SPF, DKIM y DMARC.

Los encabezados de los correos electrónicos contienen datos estructurados que los hacen requerir menos recursos para analizarlos en comparación con el cuerpo de un correo electrónico. Para entender mejor los componentes del encabezado y cuerpo de un correo electrónico, puedes leer ++Comprender el código fuente de un correo malicioso++.

Aquí es donde las blocklists se pueden usar durante la inspección del encabezado:

Consulta de la dirección IP de origen:

Esta es la dirección IP que viene en la cadena recibida de la transacción original; es decir la que generó el correo electrónico en un principio.   Esto se puede cotejar con las SBL y la AUTH BL. También se puede realizar una búsqueda rDNS cotejando con la DBL y el ZRD.

Consulta de la dirección de Reply-to:

La dirección de correo electrónico completa de este campo deberá cotejarse con la Blocklist de hash (HBL), que contiene hashes criptográficos de direcciones de correo electrónico.

Consulta de la dirección del remitente:

Suele llamarse la dirección “Friendly From” y debe cotejarse con la HBL. El dominio contenido en dicha dirección deberá cotejarse con la DBL y el ZRD, con una búsqueda de DNS adelantada en la SBL.

Finalmente, pasamos a la inspección de contenidos ( ¡desplázate hacia arriba y piensa en todas las oportunidades que tuviste para rechazar el correo antes de que llegue a esta parte tan costosa del proceso de filtrado!).

Dominios incluidos en el cuerpo de un correo electrónico

Las URL de sitios web o los correos que están en el contenido del cuerpo deben cotejarse con la DBL, el ZRD, con una búsqueda de DNS adelantada en la SBL.   Los correos electrónicos contenidos en el cuerpo del correo también se pueden cotejar con la HBL.

Las direcciones de Bitcoin incluidas en el cuerpo del correo electrónico

Consúltalas cotejando con la HBL, que tiene una sección de criptocartera con hashes de bitcoin y otras direcciones de criptomonedas.

Archivos adjuntos de correo electrónico

Todos los archivos adjuntos deben cotejarse con la HBL, que tiene una lista de archivos de malware, además de las direcciones de correo electrónico y de criptomonedas.

¿Cómo se implementa todo esto?

Desafortunadamente, con tantas diferencias, no es posible cubrir todos los detalles operativos específicos de diversos sistemas de correo.   Aunque algunas de nuestras comprobaciones no se pueden implementar, te recomendamos consultar con el departamento de soporte del producto que estés utilizando.

Lo bueno es que tenemos dos complementos para filtros de código abierto: SpamAssassin y Rspamd, tanto para el filtrado previo a los datos (SMTP) como para el análisis de contenidos.  Aquí está también la descripción completa de qué blocklists se deben usar y dónde usarlas.

Si quieres probar las Blocklists de DNS y ejecutar tu propio servidor de correo electrónico, regístrate para acceder a los datos durante 30 días sin costo. Nos encantaría saber cómo te está yendo.