Sophos Managed Risk: configurar credenciales para análisis autenticados

Durante un análisis interno autenticado de vulnerabilidades, el escáner inicia sesión en el sistema de destino. De esta forma, puede inspeccionar archivos locales, entradas del Registro, software instalado y configuraciones que no son visibles en un análisis sin credenciales. Por lo tanto, suele detectar más vulnerabilidades. No obstante, un análisis sin autenticar sigue siendo útil, ya que refleja mejor aquello a lo que podría acceder un atacante externo que no disponga de una cuenta.

El procedimiento seguro consta de cuatro pasos:

Prepare una cuenta específica para el análisis con los permisos necesarios para las comprobaciones previstas.
Haga que el sistema operativo de destino sea accesible mediante SMB/WMI o SSH.
Cree el tipo de credencial adecuado en Managed Risk > Settings > Credentials > Add credential.
Asigne la credencial a un análisis interno de vulnerabilidades con Scan type: Authenticated y valide el resultado en el siguiente análisis.

Preparar los sistemas de destino antes de utilizar Sophos Fusion

La preparación se realiza directamente en el objetivo Windows, macOS o Linux y es independiente de la posterior introducción de las credenciales en Sophos Fusion. Aunque el formulario de Fusion esté correctamente cumplimentado, no puede compensar la falta de recursos compartidos, servicios o permisos en el objetivo.

Windows

Para endpoints y servidores Windows que no sean controladores de dominio, utilice una cuenta local específica que pertenezca al grupo local Administradores. Los controladores de dominio, en cambio, requieren un administrador de dominio y deben incluirse en un análisis independiente con sus propias credenciales. Así se evita utilizar la cuenta con más privilegios en servidores miembro o clientes.

Compruebe lo siguiente antes de asignar la credencial:

Las directivas de seguridad como Deny access to this computer from the network y Access this computer from the network, otras directivas locales, la protección de endpoints y los sistemas IPS/IDS no deben bloquear las comprobaciones de credenciales previstas.
Algunas comprobaciones locales requieren PowerShell 5.0 o una versión posterior.
El escáner necesita acceso mediante SMB y WMI. El firewall del host debe permitir conexiones desde la dirección IP del dispositivo de análisis de Managed Risk; los puertos TCP 139 y 445 son necesarios para File and Printer Sharing. Los puertos de los demás servicios que deban comprobarse también tienen que ser accesibles desde el escáner.
Los recursos compartidos administrativos IPC$, ADMIN$ y C$ deben estar disponibles.
Remote Registry debe estar en ejecución o poder iniciarse con los permisos administrativos utilizados para el análisis.
En los escenarios documentados para cuentas de Windows, Network access: Sharing and security model for local accounts debe configurarse como Classic - local users authenticate as themselves. Esto se aplica tanto a una cuenta de dominio utilizada para auditorías locales como a una cuenta local; iniciar sesión como invitado no basta para realizar comprobaciones de seguridad locales.
En el caso de las cuentas locales, UAC no debe filtrar el token de administrador remoto. Las opciones documentadas son desactivar UAC o establecer en 1 el valor DWORD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. Realice este tipo de cambio de seguridad únicamente mediante el proceso interno de gestión de cambios y limítelo a los sistemas afectados.
Para WMI, habilite las reglas de entrada predefinidas Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) y Windows Management Instrumentation (DCOM-In). Siempre que sea posible, limite las reglas a la dirección IP del dispositivo de análisis.

No sustituya estos requisitos por una regla general de firewall abierta a cualquier origen. Si el dispositivo de análisis y un objetivo se encuentran en VLAN diferentes, las especificaciones del análisis requieren que el dispositivo tenga acceso bidireccional completo a todos los puertos y protocolos de la VLAN de destino. El enrutamiento y los firewalls intermedios deben permitir ese acceso; limite las reglas al dispositivo y a los rangos de destino previstos.

macOS

Los objetivos macOS se comprueban mediante SSH, ya sea con un par de claves o con credenciales de usuario y sudo o su. Para realizar comprobaciones locales completas, la cuenta de análisis debe pertenecer al grupo de administradores y disponer de Full Disk Access. Con menos permisos todavía se pueden realizar comprobaciones concretas, como determinar el nivel de parches, pero no se obtiene la misma profundidad de inspección. La cuenta específica debe tener el mismo nombre de usuario en todos los objetivos macOS previstos; siempre que sea posible, es preferible utilizar el acceso mediante claves en lugar de credenciales de usuario.

Antes del análisis se deben cumplir los siguientes requisitos:

Habilite Remote Login y autorice la cuenta específica de análisis.
En el ajuste del sistema Remote Login, active Allow full disk access for remote users. Conceda además Full Disk Access en Privacy & Security a los dos procesos documentados: /usr/libexec/sshd-keygen-wrapper y /Library/NessusAgent/run/sbin/nessus-service.
Para utilizar Kerberos, sshd debe ser compatible con Kerberos, utilizar el método de interacción gssapi-with-mic y disponer de una resolución DNS inversa que funcione correctamente.
El servidor SSH y el escáner deben tener al menos un cifrado compatible en común. Los cifrados documentados son blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc y AES-CTR. No habilite de forma generalizada un cifrado obsoleto solo para el análisis; compruebe primero si ya existe una opción segura común.
Para el acceso basado en claves, añada la clave pública a authorized_keys para la cuenta específica y facilite la clave privada al escáner únicamente de forma protegida.

Linux

Los objetivos Linux también se comprueban mediante SSH, ya sea con un par de claves o con credenciales de usuario y sudo o su. Para obtener la máxima profundidad de inspección posible, la cuenta debe poder ejecutar comandos con privilegios de root. Una cuenta con menos privilegios puede proporcionar resultados parciales, pero no permite realizar todas las comprobaciones de configuración y archivos.

Compruebe lo siguiente antes del análisis:

Cree un usuario SSH específico que tenga exactamente el mismo nombre en todos los objetivos previstos. Para la autenticación exclusiva mediante claves, la cuenta no debe tener una contraseña válida; añada la clave pública a authorized_keys y mantenga protegida la clave privada en el escáner.
Permita la conexión SSH y la elevación de privilegios prevista desde la red del dispositivo de análisis.
Para utilizar Kerberos, sshd debe ser compatible con Kerberos, utilizar gssapi-with-mic y disponer de una resolución DNS inversa que funcione correctamente.
La configuración del shell de la cuenta de análisis requiere una variable PS1 de al menos cuatro caracteres. Un indicador muy corto, como PS1='$ ', puede ralentizar considerablemente el análisis.
Las opciones de cifrado SSH documentadas son las mismas que para macOS. Utilice algoritmos seguros que ya sean comunes a ambos sistemas y no amplíe innecesariamente la configuración del host.

La preparación general de un host SSH puede admitir tipos de clave más modernos. Sin embargo, en Managed Risk > Settings > Credentials, Public Key solo admite actualmente claves RSA y DSA en formato OpenSSH. Por tanto, un tipo de clave que no sea compatible en esa sección no podrá utilizarse aunque se modifique el sistema de destino.

Crear una credencial en Sophos Fusion

En Managed Risk > Settings, abra la pestaña Credentials y seleccione Add credential. En Create credential, seleccione primero el tipo. No se admite la autenticación Plaintext.

SNMPv3

SNMPv3 está destinado a dispositivos de red que utilizan SNMP versión 3. Rellene los siguientes campos:

Credential type: SNMPv3.
Credential name: un nombre único, por ejemplo, snmpv3-core-switches.
Description: una nota opcional sobre el conjunto de dispositivos previsto.
Username: el usuario de la cuenta SNMPv3.
Port: 161 de forma predeterminada; cámbielo solo si el objetivo ofrece SNMPv3 en otro puerto.
Security Level: Authentication and privacy. Esta combinación de autenticación y cifrado es actualmente la única opción.
Authentication algorithm: SHA-256, SHA-384 o SHA-512, según la configuración del objetivo.
Authentication password: la contraseña de autenticación de la cuenta SNMPv3.
Privacy algorithm: AES-256 o AES-256C, según la configuración del objetivo.
Privacy password: la contraseña de privacidad de la cuenta SNMPv3.
Seleccione Create para guardar.

Windows

Para Credential type: Windows, introduzca primero un Credential name único y, si lo desea, una Description. A continuación, seleccione una de las tres opciones de Authentication method:

Kerberos: introduzca Username, Password, Domain, Key Distribution Center (KDC), KDC Port (valor predeterminado: 88), KDC Transport (TCP o UDP) y Realm.
NTLM Hash: introduzca Username, Hash y Domain. Trate los hashes NTLM como contraseñas y no los incluya nunca en material de diagnóstico.
Password: introduzca Username, Password y, si fuera necesario, el campo opcional Domain.

Seleccione Create para guardar. En el caso de las cuentas locales, el usuario debe corresponder al objetivo en cuestión; para analizar controladores de dominio, utilice las credenciales de administrador de dominio reservadas para ese fin.

SSH para Linux y macOS

Para Credential type: SSH, introduzca un Credential name único, una Description opcional y, a continuación, seleccione el valor de Authentication method:

Kerberos: introduzca Username, Key Distribution Center (KDC), KDC Port (valor predeterminado: 88), KDC Transport (TCP o UDP) y Realm.
Password: introduzca Username y Password. Seleccione Elevate privileges with únicamente si así lo requiere la configuración preparada en el objetivo.
Public Key: introduzca Username. En Private key, utilice Add File para cargar el archivo de la clave privada o pegue la clave directamente. Solo se admiten claves RSA y DSA en formato OpenSSH. Si la clave está protegida, introduzca también el valor de Private key passphrase.

Para Public Key, seleccione Nothing o sudo en Elevate privileges with. Si elige sudo, introduzca también sudo user y, si fuera necesario, sudo password. La cuenta y el método de elevación elegidos deben corresponder a la configuración preparada en el objetivo.

Si lo desea, introduzca nombres de host, direcciones IP o bloques CIDR en Targets para dar prioridad a esta credencial de clave pública en esos objetivos. Separe los distintos valores mediante comas o espacios. Esta prioridad no sustituye ni la definición de los objetivos del análisis ni la selección de credenciales en el análisis.

Seleccione Create para guardar.

VMware ESX SOAP API

Este tipo está destinado a hosts VMware ESX/ESXi:

Credential type: VMware ESX SOAP API.
Credential name: un nombre único.
Description: una nota opcional sobre los hosts previstos.
ESX SOAP API Authentication Method: Username and Password. Esta es actualmente la única opción.
Username: una cuenta de VMware con acceso administrativo al host ESX/ESXi.
Password: la contraseña de esta cuenta.
Seleccione Create para guardar.

Para realizar comprobaciones exhaustivas, esta cuenta necesita acceso administrativo al host. La credencial está destinada a entornos de virtualización VMware, no a objetivos Windows o SSH dentro de las máquinas virtuales.

Asignar la credencial a un análisis autenticado

Las credenciales guardadas no inician un análisis por sí solas. En My Products > Managed Risk > Scans > Internal, cree un análisis interno de vulnerabilidades y configúrelo en la página Create Vulnerability Scan de la siguiente manera:

En Select scanner, seleccione el dispositivo de análisis conectado.
En Configure scan details, introduzca un nombre y una descripción.
Establezca Scan type en Authenticated.
En Select credentials, seleccione las credenciales adecuadas. Cada análisis puede utilizar un máximo de diez credenciales.
En Add scan targets, introduzca las direcciones IP, los rangos CIDR o los nombres de host previstos y seleccione Add. Confirme con la tecla Intro cada valor que introduzca individualmente; las listas pegadas deben estar separadas por comas.
En Schedule the weekly scan, establezca el día, la hora y la zona horaria y, a continuación, seleccione Save en la esquina superior derecha.

Separe las credenciales por sistema operativo, zona de confianza y requisitos de protección. En concreto, una credencial de administrador de dominio no debe formar parte de un análisis amplio de clientes Windows normales. Si necesita más de diez credenciales, divida los objetivos en análisis con un alcance comprensible en lugar de combinar credenciales o ampliar permisos.

Probar la credencial de Windows antes del siguiente análisis

Las pruebas de credenciales documentadas solo son aplicables actualmente a Windows. Ejecútelas desde un sistema Windows que esté en la misma subred que el dispositivo de análisis y utilice exactamente las mismas credenciales. Así se reproducen con la mayor fidelidad posible las condiciones de red del escáner.

Abra Command Prompt o PowerShell como administrador. En el ejemplo, 192.0.2.25 es una dirección reservada para documentación y debe sustituirse por la dirección IP interna del sistema de destino. LAB-SRV-025\svc_mrisk es un ejemplo de cuenta local; para una cuenta de dominio, utilice su propio formato DOMAIN\User.

Comprobar IPC$ y ADMIN$

net use \\192.0.2.25\ipc$ /user:LAB-SRV-025\svc_mrisk *
net use \\192.0.2.25\admin$ /user:LAB-SRV-025\svc_mrisk *

Introduzca la contraseña cuando aparezca la solicitud oculta después de cada comando. The command completed successfully confirma las credenciales y el acceso SMB correspondiente para esta prueba. Si la comprobación de ADMIN$ se realiza correctamente, también demuestra que la cuenta tiene acceso al recurso compartido administrativo.

Comprobar Remote Registry

reg query \\192.0.2.25\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir

La aparición de una línea del Registro para ProgramFilesDir confirma que se puede acceder a Remote Registry mediante la sesión existente. Si aparece The network path was not found, compruebe primero el servicio, la ruta SMB y el firewall; si aparece Access is denied, compruebe los permisos de la cuenta, el token remoto de UAC y la identidad que se está utilizando realmente.

Comprobar WMI

wmic /node:"192.0.2.25" /user:"LAB-SRV-025\svc_mrisk" /password:* os get name

Introduzca la contraseña únicamente cuando se le solicite. Si aparece el nombre de un sistema operativo bajo Name, se confirma el acceso mediante WMI para esta prueba. Si wmic no está disponible en la versión de Windows utilizada, no recurra a un comando alternativo que no se haya probado. En su lugar, compruebe las reglas de firewall de WMI y la preparación del host, y realice la validación propiamente dicha en el siguiente análisis de Managed Risk.

Cerrar siempre las sesiones

Después de la prueba, elimine ambas conexiones aunque haya fallado un paso intermedio:

net use \\192.0.2.25\ipc$ /delete
net use \\192.0.2.25\admin$ /delete

A continuación, utilice net use para confirmar que ya no aparece ninguna conexión con el objetivo de prueba y cierre el terminal administrativo.

Validar el resultado en el siguiente análisis

Después de la siguiente ejecución programada, compruebe en Managed Risk > Report History si se ha creado el informe interno de vulnerabilidades. Los resultados autenticados suelen ser más detallados que los resultados sin autenticar. Sin embargo, un número concreto de hallazgos no constituye un criterio de éxito: el sistema operativo, los puertos abiertos, el software instalado, los plugins utilizados y el tipo de análisis influyen en el resultado.

Para realizar una comprobación fiable:

Confirme que Scan type: Authenticated y las credenciales previstas estén seleccionados en el análisis.
Asegúrese de que los sistemas de destino estén incluidos en el alcance del análisis y sean accesibles desde el dispositivo de análisis.
En Windows, compruebe primero las cuatro áreas IPC$, ADMIN$, Remote Registry y WMI.
En Linux y macOS, compruebe la conectividad SSH, la configuración de claves o Kerberos y la elevación de privilegios prevista.
Compruebe si los firewalls del host o los intermedios bloquean el tráfico procedente de la dirección IP del dispositivo de análisis.
Solo entonces debe modificar los campos de la credencial y volver a validarlos en el siguiente análisis.

Si los resultados siguen pareciéndose a los de un análisis sin autenticar o continúan estando incompletos de forma inesperada, cree una solicitud para el equipo de Managed Risk en Threat Analysis Center > Cases > Create case > Managed Risk service request. Incluya el nombre del análisis, el intervalo de tiempo con su zona horaria, el nombre del escáner, el tipo de objetivo, el tipo de credencial, los objetivos afectados anonimizados, el resultado observado y las comprobaciones ya realizadas. No adjunte contraseñas, hashes, claves privadas ni salidas completas de consola que contengan información confidencial.

Editar o eliminar credenciales

Para editar una credencial, vaya a Managed Risk > Settings > Credentials, abra el menú de tres puntos de la columna Actions, seleccione Edit, modifique los campos y seleccione Update para guardar. Valide el cambio en el siguiente análisis previsto.

Antes de eliminar una credencial, compruebe primero todas las configuraciones de análisis que la utilizan. A continuación, seleccione Delete en el mismo menú de tres puntos y elimínela definitivamente seleccionando Confirm en el cuadro de diálogo. Al eliminar una credencial, se quita de todas las configuraciones de análisis en las que se utilizaba, lo que puede afectar a futuras ejecuciones autenticadas. Después, abra cada análisis afectado, compruebe las credenciales que siguen seleccionadas y asigne una credencial de sustitución previamente preparada si fuera necesario.

El icono de actualización situado en la esquina superior derecha vuelve a cargar la lista de credenciales. Este icono confirma que la vista de lista se ha actualizado, pero no que una credencial funcione en un objetivo; solo la prueba o el siguiente análisis pueden demostrarlo.