El reenvío automático es perjudicial
Permitir a los usuarios reenviar sus correos electrónicos fuera de Exchange Online es perjudicial, especialmente si no mantienen una copia de los mensajes reenviados en su buzón. Además de eliminar los correos electrónicos de los controles impuestos por las políticas de gobernanza de datos, crea un riesgo de que la información confidencial viaje fuera de la organización, incluso cuando un atacante hackea un buzón y configura el reenvío sin el conocimiento del propietario del buzón. Esto se hace para comprender el tráfico que recibe el usuario hackeado en preparación para ejecutar un ataque de compromiso de correo electrónico empresarial.
En esta serie de dos partes, primero analizo cómo restringir a los usuarios de OWA para crear direcciones de reenvío automático utilizando RBAC. El segundo artículo describe algunos otros bloqueos que se aplican a todos los clientes para evitar la fuga de correos electrónicos de la organización.
¿Quién está reenviando automáticamente?
El reenvío es una función del servidor, por lo que una vez que un usuario configura una dirección de reenvío en OWA, cualquier correo electrónico que llegue al buzón se reenvía. Para averiguar si actualmente se está reenviando el correo, ejecute el comando:
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} -ResultSize Unlimited | Format-Table DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward -AutoSize
DisplayName ForwardingSmtpAddress DeliverToMailboxAndForward
----------- --------------------- --------------------------
Vasil Michev (Technical Guru) smtp:[email protected] True
Ståle Hansen smtp:[email protected] True
Eoin Redmond smtp:[email protected]
Puede tomar medidas para resistir los ataques mediante la capacitación de los usuarios, pero es mejor cortar la capacidad de reenviar correos electrónicos. Podemos hacer esto creando una nueva política de asignación de roles de usuario que no incluya los parámetros del cmdlet necesarios para que un usuario cree un reenvío automático.
Cómo configurar una dirección de reenvío automático
La opción de OWA para redireccionar automáticamente mensajes desde Exchange Online (o en el entorno local) se encuentra en la sección Correo de la configuración de OWA (Figura 1).
Después de establecer una dirección de redireccionamiento automático, OWA informa al usuario en lo que ahora se llama el Administrador de Cuenta de OWA en la barra de menú (Figura 2).
Control de Acceso Basado en Rol y Exchange
El nuevo OWA cuenta con una interfaz mejorada, y el Control de Acceso Basado en Rol (RBAC) que ha existido desde Exchange 2010 sustenta esa nueva apariencia brillante, al igual que lo hace el Centro de Administración de Exchange (EAC).
RBAC funciona permitiendo el acceso a cmdlets de PowerShell y sus parámetros. Si no puedes ejecutar un cmdlet o pasar un valor en un parámetro, pierdes el acceso a una función. La política de asignación de roles aplicada a un buzón está compuesta por un conjunto de roles, cada uno de los cuales controla el acceso a una o más funciones. Clientes como OWA utilizan RBAC para saber cuándo una función está disponible para un usuario. Si su buzón está bloqueado para una función porque la política asignada no incluye el acceso correcto, el usuario no muestra la función. Es un sistema simple y efectivo. Al menos, en teoría.
Puede crear y asignar políticas de asignación de roles de usuario a través de la sección Permisos de EAC. La interfaz de usuario funciona bien si desea excluir una gran cantidad de funcionalidades como la capacidad de seleccionar etiquetas de retención personales. No le permite recortar la funcionalidad de manera más precisa, como permitir a las personas administrar listas de distribución que poseen mientras se elimina la capacidad de crear nuevas listas. Es necesario utilizar PowerShell para realizar este tipo de cambios.
Crear un nuevo rol de RBAC
RBAC para Exchange Online funciona según la restricción de los usuarios para poder ejecutar cmdlets hasta el nivel del parámetro. Los administradores pueden ejecutar todos los cmdlets y todos los parámetros debido a los roles que poseen. Los usuarios normales tienen un conjunto más restringido de asignaciones de roles, por lo que pueden hacer menos. Por ejemplo, para configurar una dirección de reenvío automático en PowerShell, se ejecuta el cmdlet Set-Mailbox utilizando un comando como:
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Por lo tanto, para evitar que los usuarios puedan crear una dirección de reenvío automático, necesitamos eliminar la capacidad de ejecutar el cmdlet Set-Mailbox con el parámetro ForwardingSmtpAddress.
El primer paso para implementar un bloqueo con RBAC es crear un nuevo rol de administración utilizando el rol existente MyBaseOptions como plantilla. Esto significa que todas las opciones admitidas en MyBaseOptions, incluida la capacidad de configurar una dirección de reenvío automático, son heredadas por el nuevo rol.
New-ManagementRole MyBaseOptions-NoForward -Parent MyBaseOptions
Deshabilitar parámetros de cmdlets en un rol.
No queremos eliminar todo el acceso a Set-Mailbox porque este cmdlet se utiliza para gestionar otros ajustes como establecer una notificación de fuera de la oficina, pero queremos deshabilitar el acceso a los parámetros utilizados en la opción de OWA. Así es cómo eliminar los dos parámetros del cmdlet en las opciones permitidas en el nuevo rol de gestión.
Set-ManagementRoleEntry MyBaseOptions-NoForward\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward, ForwardingSmtpAddress
Creación de una Política de Asignación de Roles
Ahora tenemos un rol personalizado y necesitamos combinarlo con los otros roles que los usuarios suelen recibir en una política de asignación de roles de usuario para crear una nueva política. Este comando crea una nueva política de asignación de roles de usuario que combina los roles base y nuestro rol personalizado.
New-RoleAssignmentPolicy -Name PolicyWithNoEmailForward -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoForward -Description "User role assignment policy that restricts the assignees from being able to autoforward email outside the organization"
Nota: Si los roles básicos se han actualizado, esos cambios se trasladan a la nueva política. Puedes verificar las asignaciones abriendo la política en EAC (Figura 3).
El enfoque alternativo es actualizar la política de asignación de roles de usuario predeterminada a través de EAC para que se parezca a la Figura 3. La desventaja es que dicho cambio afectará a cada buzón al que se asigne la política (a menudo a todos los buzones de la organización). Es posible que no desees hacer esto, por lo que una nueva política podría ser la mejor opción.
Aplicación de la Nueva Política de Asignación de Roles de Usuario
Las políticas de asignación de roles de usuario se aplican a los buzones mediante la ejecución del cmdlet Set-Mailbox. Aquí asignamos la política a un buzón.
Set-Mailbox -Identity James.Ryan -RoleAssignmentPolicy PolicyWithNoEmailForward
Se tarda un poco en que la nueva política sea efectiva. Cuando lo sea, el usuario no podrá establecer una dirección de reenvío porque OWA notará que la política no incluye los parámetros del cmdlet necesarios y suprimirá la interfaz de usuario (Figura 4).
PowerShell facilita asignar políticas a un gran número de buzones de correo de una vez. Aquí encontramos el conjunto de buzones que tienen una dirección de reenvío automático y les asignamos la nueva política. Al mismo tiempo, eliminamos la dirección de reenvío automático existente para evitar que otros mensajes fluyan fuera de la organización. Este es un paso importante porque la asignación de la política deshabilita la capacidad de establecer nuevos reenvíos. No hace nada para eliminar las direcciones de reenvío existentes.
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} |
Set-Mailbox -RoleAssignmentPolicy "PolicyWithNoEmailForward" -ForwardingSmtpAddress $Null -DeliverToMailboxAndForward $False
En este punto, probablemente sería una buena idea enviar una nota cortés a los propietarios de los buzones afectados para informarles la buena noticia de que el correo electrónico permanecerá dentro de la organización.
Como última comprobación, para descubrir qué buzones tienen nuestra nueva política, ejecute:
Get-mailbox -RecipientTypeDetails UserMailbox | ?{$_.RoleAssignmentPolicy -eq "PolicyWithNoEmailForward"} | Format-Table DisplayName, RoleAssignmentPolicy
DisplayName RoleAssignmentPolicy
----------- --------------------
Kim Akers PolicyWithNoEmailForward
Vasil Michev PolicyWithNoEmailForward
Ståle Hansen PolicyWithNoEmailForward
Eoin Redmond PolicyWithNoEmailForward
Si es necesario, un administrador puede restablecer el reenvío automático en el buzón ejecutando Set-Mailbox (ejemplo a continuación) o actualizando el buzón a través de EAC. RBAC no se aplica en estos contextos administrativos.
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Parte Uno de la Solución
Detener que los usuarios de OWA creen direcciones de reenvío automático es un buen primer paso para prevenir el reenvío automático de mensajes fuera de la organización. Sin embargo, es solo el primer paso. Otros clientes y aplicaciones tienen sus propias formas de automatizar el reenvío, por lo que es importante abordar el problema de manera coherente.
El siguiente paso es considerar qué otras barreras se pueden erigir para detener el reenvío automático. Eso está en el artículo 2 de esta serie.
Source:
https://petri.com/stop-owa-users-autoforwarding-email/