Firewall - Permitir la red interna de WMI

3

No estoy totalmente seguro de si este es el intercambio de pila correcto para hacer esta pregunta, así que solo dime si debería estar en otro lugar.

Estoy investigando los sistemas de administración de activos de TI y, para estos sistemas, para permitir la administración remota de computadoras, necesitan tener acceso a través de los firewalls a WMI.

Mi pregunta es, ¿es esto lo suficientemente seguro como para permitir una red interna? ¿O existe una forma más segura de permitir que un sistema de administración de activos de TI tenga administración remota a las computadoras sin tener que instalar un cliente en cada computadora?

    
pregunta user3660338 16.11.2015 - 11:40
fuente

1 respuesta

3

WMI se puede proteger para que sea seguro para redes internas siguiendo algunos pasos de configuración: enlace

Confidencialidad

El problema más inmediato (para mí) es requerir el cifrado en tránsito para mitigar la indagación (extracto de arriba):

  

Un administrador o un archivo MOF pueden configurar un espacio de nombres WMI para que no se devuelvan datos a menos que use la privacidad del paquete (RPC_C_AUTHN_LEVEL_PKT_PRIVACY o PktPrivacy como moniker en un script) en una conexión a ese espacio de nombres. Esto asegura que los datos estén encriptados cuando crucen la red. Si intenta establecer un nivel de autenticación más bajo, recibirá un mensaje de acceso denegado. Para obtener más información, consulte Requerir una conexión cifrada a un espacio de nombre.

Mínimo privilegio

La siguiente cosa más importante es el menor privilegio a través de RBAC. Debe limitar la cuenta del producto de administración de activos a las operaciones de WMI de solo lectura y, si es posible, limitar lo que puede leer a lo que se necesita. Esto se logra a través de la seguridad del espacio de nombres y se describe más detalladamente aquí: enlace

Es posible que deba permitir ciertos privilegios de escritura si el software de administración de activos también realiza acciones en los puntos finales en lugar de solo la auditoría. Presione el proveedor para obtener una configuración con privilegios mínimos.

Autenticación fuerte

Una vez que tenga eso, debe generar valores aleatorios de alta entropía (utilizando todos los caracteres y la longitud máxima con la que trabajará la herramienta de administración de activos) tanto para el nombre de usuario como para la contraseña. Estas credenciales deben almacenarse en un sistema seguro de administración de contraseñas como Thycotic Secret Server o en un administrador local de contraseñas seguras como KeePass para el cual usted mantiene copias de seguridad. Probablemente pueda usar un nombre de usuario no aleatorio, pero eso aumenta el riesgo si se adivina fácilmente y usar un nombre de usuario aleatorio, dado que la poca frecuencia que necesita para administrarlo le da un impulso de seguridad gratuito.

Seguridad de la red

Después de todo esto, debe configurar el Firewall de Windows con seguridad avanzada para permitir las conexiones DCOM necesarias para WMI solo en el puerto en el que se está ejecutando y solo desde el host (o hosts si está haciendo HA) ejecutando el software de administración de activos. Esta es la capa final de la defensa en profundidad aquí y hace más difícil para los atacantes explotar incluso si tienen las credenciales.

Single Purpose Single Server / VM

El software de administración de activos debe ejecutarse solo en un servidor dedicado o máquina virtual. La lista blanca de firewall es mucho menos útil si se encuentra en un servidor de aplicaciones misceláneo con todas las demás aplicaciones no deseadas que necesita una red. Ejecutarlo con otro software o servicios también lo expone y las credenciales a riesgos de ataques locales innecesarios.

Es posible que puedas hacer esos pasos en un GPO.

Solución alternativa: PowerShell

Una alternativa (aunque incompatible con su producto de gestión de activos) es PowerShell Remoting. Utiliza autenticación TLS y GSSAPI integrada con AD, por lo que me siento muy cómodo con ella. Lo usamos en producción.

Una vez que tenga el control remoto de PowerShell, puede iniciar sesión en un sistema de forma remota con Enter-PSSession% MachineName% . También puede usar Invoke-Command con -ScriptBlock para ejecutar un comando de forma remota y obtener resultados de manera centralizada para la coordinación. Sus comandos WMI podrían ejecutarse de esa manera.

Aquí hay una guía para habilitar el control remoto de PowerShell: enlace

Conclusión

El desafío con cualquiera de estos es la confianza transitiva y el movimiento lateral. Tenga cuidado de que las cuentas permitidas para realizar este salto entre máquinas tengan contraseñas muy seguras. Usamos contraseñas generadas al azar ASCII completas de 100 caracteres por persona para esto que rotamos cada 90 días. Usamos KeePass para autografiarlos, ya que no son prácticos para escribir a mano.

    
respondido por el Alain O'Dea 16.11.2015 - 12:43
fuente

Lea otras preguntas en las etiquetas