Alfredo, parte de este staff, nos hizo el favor de redactar esta crónica ya que controla a la perfección este tema.
Solución:
tl; dr
Es muy fácil falsificar un dominio incluso con los controles SPF habilitados.
La solución es usar DKIM + DMARC, o SPF + DMARC
El cliente de correo electrónico es responsable de informarle si el mensaje pasa DMARC Mostrar desde verificación
El protocolo de correo electrónico permite la suplantación de identidad legítima mediante los encabezados Resent- * y los encabezados del remitente. El cliente de correo electrónico (MUA) debería mostrar esta excepción siempre que exista.
Hay algunos conceptos erróneos sobre el SPF, a saber:
- SPF no evita la suplantación de correo electrónico.
- El SPF por sí solo no afecta, influye ni controla el RFC 2822 Mostrar desde.
- De forma predeterminada, la utilidad de SPF es evitar problemas de retrodispersión y escenarios de suplantación de identidad muy simples.
Microsoft intentó resolver este problema con SenderID (haciendo que SPF se aplicara a la dirección Display From), pero era demasiado complicado y realmente no resolvió todo el problema.
Algunos antecedentes
Primero, sepa que hay dos direcciones “de” y dos direcciones “a” en cada mensaje SMTP. Uno se conoce como el sobre RFC2821 y el otro es el mensaje RFC2822. Sirven para diferentes propósitos
El sobre: (RFC2821)
-
El sobre son metadatos que no aparecen en el encabezado SMTP. Desaparece cuando el mensaje pasa al siguiente MTA.
-
los
RCPT From:es donde irán los NDR. Si un mensaje proviene de Postmaster o de un servicio de retransmisión, generalmente es<>o[email protected]. Es interesante ver que Salesforce utiliza esto de manera similar a ConstantContact como un key en una base de datos como[email protected]para ver si el mensaje rebotó. -
los
RCPT TO:es a quién se está enviando el mensaje. Se utiliza tanto para usuarios “para” como “bcc”. Por lo general, esto no afecta la “visualización de direcciones” en el cliente de correo, pero hay ocasiones en las que los MTA mostrarán este campo (si los encabezados RFC2822 están dañados).
El mensaje (RFC2822)
-
La parte del mensaje comienza cuando el
datase emite el comando. -
Esta información incluye los encabezados SMTP con los que está familiarizado, el mensaje y sus archivos adjuntos. Imagine que todos estos datos se copian y pegan de cada MTA al siguiente, en sucesión hasta que el mensaje llega a la bandeja de entrada.
-
Es habitual que cada MTA prefix lo mencionado anteriormente, copiar y pegar con información sobre el MTA (IP de origen, IP de destino, etc.). También pega los detalles de la verificación SPF.
-
Este es el
Display Fromes colocado. Esto es importante. Los spoofers pueden modificar esto. -
los
Mail From:en el sobre se desecha y generalmente se coloca aquí como elreturn-path:dirección para NDR
Entonces, ¿cómo evitamos que las personas modifiquen el Mostrar desde? Bueno, DMARC redefine un segundo significado para el registro SPF. Reconoce que existe una diferencia entre la Sobre de y el Mostrar desdey que existen razones legítimas para que no coincidan. Dado que SPF se definió originalmente para que solo se preocupara por Envelope From, si Display From es diferente, DMARC requerirá una segunda verificación de DNS para ver si el mensaje está permitido desde esa dirección IP.
Para permitir escenarios de reenvío, DMARC también permite Mostrar desde estar firmado criptográficamente por DKIM, y si cualquier spammer o phisher no autorizado intentara asumir esa identidad, el cifrado fallaría.
¿Qué es DKIM? DKIM es una tecnología criptográfica ligera que firma los datos que residen en el mensaje. Si alguna vez recibió un mensaje de Gmail, Yahoo o AOL, entonces sus mensajes estaban firmados con DKIM. El punto es que nadie sabrá que está utilizando el cifrado y la firma DKIM a menos que mire en los encabezados. Es transparente
Por lo general, DKIM puede sobrevivir al reenvío y la transferencia a diferentes MTA. Algo que SPF no puede hacer. Los administradores de correo electrónico pueden utilizar esto en nuestro beneficio para evitar la suplantación de identidad.
El problema radica en que el SPF solo verifica el sobre RFC2821, y no el Mostrar desde. Dado que la mayoría de la gente se preocupa por Mostrar desde que se muestra en un mensaje de correo electrónico, y no en la ruta de retorno NDR, necesitamos una solución para proteger y asegurar esta pieza.
Aquí es donde entra DMARC. DMARC le permite usar una combinación de una verificación de SPF modificada o DKIM para verificar la Mostrar desde. DKIM le permite firmar criptográficamente la pantalla RFC2822 desde siempre que el SPF no coincida con el Mostrar desde (que sucede con frecuencia).
Tus preguntas
¿Por qué todavía es posible falsificar el encabezado “De:” en los correos electrónicos?
Algunos administradores de servidores no han implementado las últimas tecnologías para evitar que suceda este tipo de cosas. Una de las principales cosas que impiden la adopción de estas tecnologías son los “servicios de reenvío de correo electrónico”, como un software de listas de correo, reenviadores automáticos o reenvío de alumnos de la escuela (.forwarder). A saber:
-
SPF o DKIM no están configurados.
-
No se ha configurado una política de DMARC.
-
El cliente de correo electrónico no muestra los resultados de la verificación del Mostrar desde y el campo Reenvío- * o Remitente.
¿Qué impide que los usuarios simplemente descarten los correos electrónicos en los que el dominio de origen del remitente no coincide con el dominio del servidor SMTP?
¿Qué no coincide: el sobre o el cuerpo? Bueno, de acuerdo con los estándares de correo electrónico, el sobre no debería coincidir si está pasando por un reenvío. En ese caso, necesitamos que DKIM firme el Display From y asegurarnos de que MUA verifique esto.
Finalmente, el MUA (cliente de correo electrónico) debe mostrar si el remitente está verificado por DMARC y si alguien está tratando de anularlo con un Remitente o Resentido de encabezamiento.
¿Qué impide que los usuarios simplemente descarten los correos electrónicos en los que el dominio de origen del remitente no coincide con el dominio del servidor SMTP?
Nada. Se les permite, y muchos lo utilizan para filtrar el spam.
Como muchas tecnologías con deficiencias de seguridad, el correo electrónico no se diseñó teniendo en cuenta la seguridad y la autenticación. El propósito del campo “de” era más o menos el mismo que para un sobre de correo tradicional. Para que el correo electrónico sea utilizable a la luz de las necesidades y los abusos del siglo XXI, hemos tenido que añadir adjuntos. Específicamente, SPF aborda la primera parte de su pregunta:
Con tantos proveedores de correo electrónico populares que obligan a los usuarios a iniciar sesión utilizando sus servidores SMTP, ¿por qué todavía es posible falsificar el encabezado “De:” en los correos electrónicos?
La solución es verificar el encabezado / IP en el momento de la recepción. Si bien esto no evita técnicamente la falsificación real del encabezado, hace que los encabezados falsificados sean menos útiles.
Ya hay parcial protección contra eso: https://en.wikipedia.org/wiki/Sender_Policy_Framework
Todos los proveedores de correo electrónico populares lo utilizan. Pero manejan la falla del SPF de manera diferente, algunos proveedores de correo descartarán totalmente los mensajes en función de esa verificación, y algunos proveedores simplemente los colocarán en la carpeta de correo no deseado.
Cualquiera puede crear su propio servidor de correo electrónico e intentar enviar como cualquiera.
Puede verificar su dirección de Gmail (si tiene una) y abrir el encabezado de cualquier correo electrónico, y verá el resultado de la verificación de SPF en la parte superior:
spf=pass (google.com: domain of *****@*****.com designates 174.**.**.** as permitted sender) smtp.mail=*****@*****.com;
Te mostramos reseñas y valoraciones
Al final de todo puedes encontrar las acotaciones de otros desarrolladores, tú aún puedes dejar el tuyo si lo deseas.