Seguridad del servidor de correo: se envía a los receptores internos con una dirección de remitente falsa

1

Me di cuenta de que puedo enviar correos electrónicos desde el servidor de correo de mi empresa a receptores internos desde direcciones de remitentes internos falsificados sin problema y me pregunto si esto debería ser un problema de seguridad o no.

Escribí un pequeño script en Python para conectarme al servidor y enviar un correo electrónico de [email protected] a [email protected] y ese correo se entregó sin ningún problema. A veces se marcaba como spam, a veces no. Después de unos pocos correos electrónicos, el servidor de envío se bloqueó debido a la mala reputación. Entonces mi pregunta es: ¿Es este comportamiento realmente esperado?

Espero que esa configuración sea ideal para enviar correos electrónicos de suplantación de identidad o correo no deseado a los empleados de esa organización en particular. Por supuesto, entiendo que debería poder conectarse a un servidor smtp desde el exterior para enviar correos a receptores locales, de lo contrario no se podrían entregar correos. Pero, ¿es realmente común que no haya ningún tipo de verificación de la dirección del remitente o que sea tan débil?

Un miembro del Departamento de TI no pareció sorprendido cuando hablé con él sobre ese tema y me dijo que era un comportamiento bastante normal. Esta publicación sugiere que tiene razón: ¿Problemas con el uso de un servidor de correo que no admita la autenticación para enviar correo? . Así que verifiqué si podía hacer lo mismo con mi proveedor de correo (consciente de la seguridad): el cliente se bloqueó antes de que pudiera enviar el correo, y la dirección del cliente y del destinatario, ambas direcciones de correo normales, fueron rechazadas. Eso es lo que esperaría de un servidor configurado correctamente. ¿Estoy equivocado aquí? ¿Es realmente insignificante?

    
pregunta Michael Helwig 19.01.2016 - 11:03
fuente

1 respuesta

1

El problema que está describiendo se conoce como spoofing , donde puede enviar un mensaje desde [email protected], aunque no sea [email protected].

Debido a que el protocolo SMTP se remonta a principios de la década de 1980, cuando Internet estaba en sus primeras etapas y era utilizado solo por un número relativamente pequeño de usuarios, los ingenieros del protocolo SMTP no previeron el problema de la suplantación de identidad. Debido a esto, los usuarios pueden enviar fácilmente mensajes que parecen haber sido enviados desde cualquier remitente que elijan.

Para contrarrestar el problema de la suplantación de identidad, han surgido métodos de autenticación de mensajes. Estos métodos se utilizan para determinar si es probable que la dirección del remitente que aparece en un mensaje sea legítima, o si es probable que haya sido falsificada. Al autenticar si es probable que se haya enviado o no un mensaje del remitente del que se dice que se envió, los filtros de correo no deseado pueden determinar con mayor precisión si un mensaje es probablemente correo no deseado. Dos estándares que se han utilizado ampliamente para la autenticación de mensajes son Sender Policy Framework (SPF) y Correo Identificado por Claves de Dominio (DKIM).

SPF es una forma de publicar las direcciones IP de los servidores de correo desde donde se autoriza el envío del correo saliente para un dominio. Esto permite que los filtros de correo no deseado determinen si un mensaje fue falsificado. Si el mensaje fue enviado desde un servidor de correo cuya dirección IP no figura en el registro SPF para el dominio del remitente supuesto, es probable que el mensaje haya sido falsificado. Los registros SPF se publican como registros TXT en el DNS para un dominio.

DKIM es otro método para autenticar mensajes. Es una consecuencia de un estándar anterior, conocido como DomainKeys, y se basa en la criptografía de clave pública y las firmas digitales. Al usar DKIM, el mensaje está firmado digitalmente por una entidad, que puede ser el remitente o un tercero. La clave pública del firmante, que se utiliza para verificar la firma, se publica en el DNS de su dominio. Cuando se firma un mensaje, la firma DKIM se coloca en el encabezado del mensaje. Al recibir el mensaje, la firma se verifica mediante la clave pública del firmante. Si la firma es válida, esto indica que el firmante ha avalado la autenticidad del mensaje. UltraSMTP puede firmar con DKIM sus mensajes en su nombre con nuestras claves, o UltraSMTP puede firmarlos con sus claves.

El dominio de su empresa debe tener información SPF o DKIM publicada en su DNS. Si configura su MX entrante para verificar que los mensajes entrantes que parecen haber sido enviados por los usuarios en el dominio de su compañía hayan sido enviados desde un servidor SMTP incluido en el registro SPF de su compañía, o contengan una firma DKIM válida, entonces puede usar esto para marcar estos mensajes falsificados.

    
respondido por el mti2935 19.01.2016 - 12:52
fuente

Lea otras preguntas en las etiquetas