¿Buena idea? ¿Rechazar correos electrónicos entrantes con nuestro propio final de dominio? (porque deben ser falsos)

33

Tengo una pregunta sobre nuestro servidor de Exchange: ¿Crees que es una buena idea rechazar los correos electrónicos externos entrantes que tienen nuestro propio dominio al final?

¿Te gusta el correo electrónico externo fake@example.com?

¿Porque si fuera de un remitente real en nuestra empresa, el correo electrónico nunca vendría de afuera?

En caso afirmativo, ¿cuál es la mejor manera de hacer esto?

security email-server exchange-2013

— Steffen Maier
fuente

3

¿Tiene algún tipo de solución de filtrado de spam en este momento?

— ewwhite

14

Debe verificar que no tenga ningún proveedor de aplicaciones web que intente enviar desde su propio dominio. Por ejemplo, si tiene un sistema de nómina que podría enviar correos electrónicos a su personal desde "nómina@ejemplo.com". También verifique si marketing o RR.HH. podrían usar un servicio de correo masivo externo y si desean que el personal reciba esos mensajes. Por lo general, esos mensajes tienen un remitente o al menos una dirección de respuesta de alguien en marketing o recursos humanos. En esas situaciones, generalmente podrá colocar los servidores de correo electrónico del servicio en una lista de permisos y aún así bloquear su propio dominio entrante (eso es lo que hacemos).

— Todd Wilcox

66

@NeilMcGuigan ¿Qué importaría eso? ¿El correo aún debe originarse en un servidor de correo interno? No vendría de fuera de la red solo porque no está físicamente presente.

— Matt

@Matt gotya, brainfart

— Neil McGuigan

1

Si tiene notificaciones automáticas por correo electrónico que provienen de uno de sus servidores, por ejemplo, notificaciones fallidas de trabajos cron o intentos de incumplimiento de IDS o monitor de uso de recursos, y están configurados de modo que su dirección De sea con su nombre de dominio. Deberá tener cuidado de enrutar esos correos electrónicos a través de su servidor de correo interno o de incluir en la lista blanca a esos servidores como remitentes permitidos.

— Mentira Ryan

53

Sí, si sabe que el correo electrónico para su dominio solo debe provenir de su propio servidor, debe bloquear cualquier correo electrónico para ese dominio que se origine en un servidor diferente. Incluso si el cliente de correo electrónico del remitente se encuentra en otro host, debe iniciar sesión en su servidor (o en el servidor de correo electrónico que utilice) para enviar correos electrónicos.

Dando un paso más allá, puede configurar su servidor para verificar los registros SPF. Así es como muchos hosts evitan ese tipo de actividad de correo electrónico. Los registros SPF son un registro DNS, un registro TXT, que proporciona reglas sobre qué servidores pueden enviar correos electrónicos para su dominio. Cómo habilitar la verificación de registros SPF dependería de su servicio de correo electrónico y estaría más allá del alcance de lo que debe cubrir aquí. Afortunadamente, la mayoría de los entornos de alojamiento y software tendrán documentación para trabajar con registros SPF. Es posible que desee obtener más información sobre SPF en general. Aquí está el artículo de Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— Ding
fuente

3

@Kurtovic, un servidor de correo electrónico bien configurado debe rechazar el correo electrónico que rechaza, para que se notifique al remitente.

— Calimo

8

@Calimo No cuando rechaza el correo electrónico por ser spam. Hacerlo permitiría al spammer seguir intentándolo hasta que haya aprendido lo que su algoritmo permite y no permite.

— Jon Bentley

27

@Calimo - no. aceptar y rebotar es lo peor que puede hacer, está contribuyendo al spam de dispersión inversa y SERÁ incluido en la lista negra muy rápidamente. simplemente rechace el correo no deseado; lidiar con eso es el problema del host de envío . Si no puede hacerlo, acepte, verifique y descarte si es spam o malware. nunca aceptes y rebotes.

— cas

2

@cas: hay una tercera alternativa: rechazar en el momento de aceptación de SMTP. Esto deja la carga de producir una respuesta de error en el servidor SMTP remitente, si así lo desea, y por lo tanto permite que muchos remitentes legítimos vean si su correo fue rechazado al tiempo que garantiza que nunca producirá spam usted mismo.

— R ..

2

@R ... creo que descubrirá que esa no es una tercera alternativa, es una paráfrasis de lo que dije "simplemente rechace el correo no deseado; lidiar con eso es el problema del host de envío".

— cas

31

Ya existe un estándar para hacerlo. Se llama DMARC . Lo implementa con la firma DKIM (que es una buena idea implementar de todos modos).

La descripción general de alto nivel es que firmas cada correo electrónico que deja tu dominio con un encabezado DKIM (lo cual es una buena práctica de todos modos). Luego configura DMARC para rechazar cada correo electrónico que llegue a su servidor de correo, desde un dominio que posee, que no esté firmado con un encabezado DKIM válido.

Esto significa que aún puede hacer que los servicios externos envíen correos electrónicos a su dominio (como el software de servicio de asistencia alojado, etc.), pero puede bloquear los intentos de phishing.

La otra gran cosa sobre DMARC es que recibe informes de fallas, por lo que puede administrar el manejo de excepciones según sea necesario.

El inconveniente es que debe asegurarse de tener todo resuelto de antemano o puede comenzar a soltar correos electrónicos legítimos.

— Mark Henderson
fuente

3

Es muy recomendable implementar SPF y DKIM antes de probar DMARC.

— Todd Wilcox

¿Cómo puede trabajar DMARC con los correos electrónicos que provienen de un servidor diferente al suyo, como con servicios externos, ya que su servidor no los firmará?

— jpaugh

1

@jpaugh agrega la clave pública de otros servidores a sus registros DMARC en su DNS. Podrán darle el registro para agregar.

— Mark Henderson

Hice +1 en esta respuesta porque es técnicamente correcta, para eso es exactamente DMARC y para qué sirve, pero DMARC es una muy mala idea si quieres interoperar con cosas como listas de correo, ya que viola RFC y generalmente se porta mal.

— MadHatter apoya a Monica el

11

Es probable que este bloqueo reduzca el correo basura y posiblemente dificulte la ingeniería social, pero también puede bloquear el correo legítimo. Los ejemplos incluyen servicios de reenvío de correo, listas de correo, usuarios con clientes de correo mal configurados, aplicaciones web que envían correo directamente desde el servidor web sin involucrar a su servidor de correo principal, etc.

Dkim puede mitigar esto hasta cierto punto al proporcionar una forma de identificar un mensaje que se envió desde su red, se pasó por una lista de correo o un reenviador y luego se recibió en su correo, pero no es una cura perfecta, algunas listas de correo romperán las firmas de dkim y aún tiene el problema de rastrear todos los puntos legítimos de origen de correo y asegurarse de que pasen por un firmante dkim.

Camine con cuidado, especialmente si implementa esto en un dominio existente.

— Peter Green
fuente

3

Tal vez, pero hay algunos casos que debe considerar antes de realizar dicho cambio.

1) ¿Alguien en su empresa utiliza algún tipo de servicio externo (por ejemplo, Survey Monkey, Constant Contact, etc.) para enviar correos electrónicos que parecen ser "de" su dominio? Incluso si no lo están haciendo hoy, ¿podrían hacerlo en el futuro?

2) ¿Hay alguna dirección externa que reenvíe a sus usuarios? Por ejemplo, suponga que la cuenta de gmail "mycompany.sales@gmail.com" reenvía a "sales@mycompany.com", y su usuario "bob@mycompany.com" envía a "mycompany.sales@gmail.com". En ese caso, el mensaje llegará desde "fuera", pero con una dirección "@ mycompany.com" De:.

3) ¿Alguno de sus usuarios está suscrito a listas de distribución externas que conservan la dirección original "De:" en los mensajes a la lista? Por ejemplo, si Bob se suscribe a "foo-list@lists.apple.com" y envía un mensaje, recibirá un mensaje entrante similar a: De: bob@mycompany.com Para: foo-list@lists.apple. com Remitente:

Si su servidor mira ingenuamente el encabezado "De:" (en lugar de "Remitente:"), podría rechazar este mensaje porque lo está recibiendo desde afuera.

Debido a todo lo anterior, tener una política general de "... de un remitente real en nuestra empresa, el correo electrónico nunca vendría de afuera" no siempre es factible.

— David Gelhar
fuente

2

Puede hacer esto en PowerShell actualizando los permisos del conector de recepción para excluir a los usuarios anónimos del envío como remitente de dominio autorizado:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Sin embargo, el problema surge cuando tiene servidores de aplicaciones remotos que necesitan enviarle correos electrónicos de estado, ya que generalmente usan su nombre de dominio en su dirección De. Es posible crear un conector de recepción adicional para sus direcciones IP específicas para que no las excluya inadvertidamente.

— Neil
fuente

1

GMail tiene una configuración en la que le permite enviar correos electrónicos con un dominio que no sea de GMail siempre que la dirección de correo electrónico se verifique por primera vez. Su decisión bloquearía esos correos electrónicos.

Si tiene o no usuarios que puedan usar esta función de GMail y si tiene sentido atenderlos depende en gran medida del comportamiento dentro de su empresa.

— cristiano
fuente

-1

SPF no solucionará esto, ya que el sobre podría tener un pase de SPF adecuado (es decir, los spammers que usan un servidor comprometido) mientras falsificarán el correo electrónico dentro del sobre. Lo que necesita es un bloque en su propio mensaje de correo electrónico de dominio que tenga un servidor de correo electrónico originario en el sobre que no sea aceptable para usted.

— Jim
fuente

"Lo que necesita es un bloque en su propio mensaje de correo electrónico de dominio que tenga un servidor de correo electrónico de origen en el sobre que no es aceptable para usted" , eso es exactamente lo que hace con SPF, crear una lista de servidores de correo electrónico legítimo de origen para su dominio.

— GAThrawn