Información técnica sobre las conexiones sin agente para sistemas Windows

Las conexiones sin agente en sistemas Windows se basan en el protocolo de conexión remota WinRM. Por lo tanto, WinRM debe estar habilitado en los activos que se van a supervisar.

WinRM HTTP utiliza por defecto el puerto 5985 y WinRM HTTPS el puerto 5986.

El correcto funcionamiento de las conexiones sin agente en Windows puede requerir algunas etapas de configuración descritas a continuación.

Requisitos previos para usar conexiones sin agente

La cuenta utilizada por Cyberwatch debe ser miembro del grupo Administradores local de los activos, ya que los scripts de análisis utilizan métodos con privilegios:

• uso de DISM (Deployment Imaging and Servicing Management) - recuperacion de versiones de KB instaladas -
• uso de la API WUA (Windows Update Agent) - eliminación / descarga / gestión de archivos .cab, gestión de los servicios WUA, despliegue de actualizaciones -
• acceso a directorios con privilegios - %APPDATA% de todos los usuarios para recuperar las versiones de las aplicaciones instaladas -
• privilegios potencialmente necesarios para la ejecución de scripts de análisis de Conformidad

Utilizar una cuenta de dominio (recomendado)

En los activos unidos a un dominio Active Directory, utilice una cuenta de dominio dedicada a Cyberwatch, miembro del grupo Administradores local de los activos que se van a supervisar. Esta pertenencia puede desplegarse mediante una GPO, con los «Grupos restringidos» o con las preferencias de directiva de grupo «Usuarios y grupos locales».

En el identificador registrado WinRM con HTTP Negotiate, introduzca la cuenta con el formato DOMINIO\usuario. Este conector se autentica en NTLM. Si el dominio restringe NTLM, utilice el conector WinRM con Kerberos descrito en la sección «Uso de WinRM-Kerberos» más abajo.

Una cuenta de dominio presenta dos ventajas con respecto a una cuenta local:

• sigue siendo utilizable en los activos que deniegan la conexión de red a las cuentas locales
• no requiere la clave de registro LocalAccountTokenFilterPolicy, ya que el UAC no filtra el token de una cuenta de dominio durante una conexión remota

Utilizar una cuenta local

En los activos fuera de dominio (grupo de trabajo), cree un usuario local Cyberwatch miembro del grupo Administradores local, por ejemplo con el siguiente comando:

$UserPassword = Read-Host -AsSecureString       # Una vez validado el comando, introduzca una contrasena para el usuario Cyberwatch
New-LocalUser "Cyberwatch" -Password $UserPassword
Add-LocalGroupMember -Group 'Administrators' -Member Cyberwatch -Verbose

El nombre del grupo Administrators varia según el idioma del sistema.

Una cuenta local requiere además la clave de registro LocalAccountTokenFilterPolicy, descrita en la sección Habilitar WinRM.

Un activo puede denegar toda conexión de red a las cuentas locales, con el derecho de usuario «Denegar el acceso a este equipo desde la red» (SeDenyNetworkLogonRight) que contiene Cuenta local o Cuenta local y miembro del grupo Administradores. Este ajuste lo exige la regla SBP-WIN-04-007 del repositorio Security_Best_Practice_Windows, así como las líneas base de seguridad de Microsoft y CIS. En estos activos, una conexión sin agente con una cuenta local falla: utilice una cuenta de dominio o el agente Cyberwatch.

Los usuarios miembros de los grupos Protected Users o gMSA no pueden usar el servicio WinRM. Asegúrese de no incluir la cuenta utilizada por Cyberwatch, de dominio o local, en ninguno de estos grupos.

Habilitar WinRM

El siguiente comando de PowerShell habilita el servicio WinRM si esta deshabilitado, y configura el firewall de Windows en consecuencia:

Enable-PSRemoting -Force

Con una cuenta local, la sola activación de WinRM no es suficiente: es necesario permitir que las cuentas de administradores locales se conecten vía WinRM, o Cyberwatch devolverá el error WinRM::WinRMAuthorizationError al crear la conexión sin agente. Este paso es innecesario con una cuenta de dominio.

Para ello, agregue la siguiente clave en el registro de Windows:

New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

Esta clave desactiva el filtrado del token por el UAC para las conexiones de red de las cuentas locales. Hace fallar la regla SBP-WIN-05-005 «Ensure UAC token filtering is not disabled for network logons» del repositorio Security_Best_Practice_Windows. Una cuenta de dominio evita este ajuste.

El siguiente comando permite verificar que el servicio WinRM esta iniciado, y lo inicia si no se ha hecho correctamente:

winrm quickconfig

Autenticación Basic y tráfico sin cifrar

Ningún conector WinRM de Cyberwatch necesita la autenticación Basic ni el tráfico sin cifrar. Los conectores WinRM con HTTP Negotiate y WinRM con Kerberos cifran cada mensaje, y el conector WinRM con SSL pasa además por TLS. El conector WinRM con texto sin cifrar a través de HTTPS solo cifra mediante TLS y recurre a la autenticación Basic cuando el servicio solo ofrece esta: es preferible utilizar WinRM con SSL.

No ejecute los comandos Set-Item WSMan:\localhost\Service\Auth\Basic $true y Set-Item WSMan:\localhost\Service\AllowUnencrypted $true, ni sus equivalentes winrm set winrm/config/service/auth @{Basic="true"} y winrm set winrm/config/service @{AllowUnencrypted="true"}, que suelen proponer guías de terceros. Juntos, permiten el envío de las credenciales en claro por la red (autenticación Basic sobre HTTP). Cada uno de ellos hace fallar la regla SBP-WIN-08-002 «Ensure WinRM does not allow Basic authentication or unencrypted traffic» del marco de cumplimiento Security_Best_Practice_Windows.

Ambos ajustes valen false por defecto. Los siguientes comandos, en una consola PowerShell iniciada como administrador, los muestran y después los restablecen:

Get-Item WSMan:\localhost\Service\Auth\Basic, WSMan:\localhost\Service\AllowUnencrypted
Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $false
Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $false

Si una GPO impone estos ajustes, Set-Item falla: la corrección debe hacerse en la GPO. Establecer en «Deshabilitada» las directivas «Permitir autenticación básica» (Allow Basic authentication) y «Permitir tráfico sin cifrar» (Allow unencrypted traffic), en las plantillas administrativas, en Windows Components > Windows Remote Management (WinRM) > WinRM Service.

Opcional - Desactivar manualmente el firewall para WinRM

A veces puede ser necesario desactivar manualmente el firewall de Windows a pesar de las operaciones anteriores, especialmente en maquinas AWS-EC2. En este caso, el error devuelto por Cyberwatch es Connection expired.

El siguiente comando de PowerShell permite autorizar solicitudes TCP entrantes en el puerto 5985 en el firewall de Windows:

netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow

Opcional - Uso de WinRM-Kerberos

El conector WinRM con Kerberos requiere una cuenta de dominio. Sustituye al conector WinRM con HTTP Negotiate cuando el dominio restringe la autenticación NTLM.

Kerberos es un protocolo de autenticación basado en el principio de un tercero de confianza. Su funcionamiento se basa en un centro de distribución de claves (KDC), que emite tickets que permiten al usuario acceder a los recursos de la red. Su funcionamiento se asemeja a los sistemas de autenticación SSO.

El proceso de autenticación Kerberos es el siguiente:

• El cliente inicia una solicitud de autenticación ante el KDC
• Si el KDC valida la autenticación, emite un ticket de concesion (TGT)
• El cliente presenta entonces el TGT para solicitar la autenticación sobre un servicio
• El servicio en cuestion devuelve el TGT al KDC para validacion
• Una vez validado, el KDC emite un ticket final que permite la autenticación del cliente en el servicio

Para que el uso de este protocolo sea posible, deben proporcionarse los siguientes datos:

• Dominio: dominio en el que se agrupan los recursos Kerberos. En el caso de una autenticación WinRM, representa el dominio de su Active Directory
• KDC: servidor de confianza que permite la distribución de tickets. En un dominio Active Directory, corresponde al FQDN del controlador de dominio
• Servidor de administracion: servidor de confianza que permite la concesion de tickets de servicio a los clientes. En un dominio Active Directory, corresponde al FQDN del controlador de dominio

A continuación, debe proporcionar un par usuario/contraseña autorizado a autenticarse en el dominio Active Directory indicado.

Requisitos previos para usar WinRM-Kerberos

El servidor Cyberwatch debe poder resolver los nombres de dominio de:

• el KDC (Key Distribution Center)
• el servidor de administración
• cada activo que se va a supervisar