Sophos Managed Risk: configurar credenciais para verificações autenticadas

Durante uma verificação de vulnerabilidades interna autenticada, o scanner inicia sessão no sistema de destino. Isto permite-lhe inspecionar ficheiros locais, entradas de registo, software instalado e configurações que não são visíveis numa verificação sem credenciais. Por isso, geralmente deteta mais vulnerabilidades. Uma verificação não autenticada continua, no entanto, a ser útil: reflete melhor aquilo a que um atacante externo sem conta conseguiria aceder.

O procedimento seguro está dividido em quatro etapas:

Prepare uma conta de verificação dedicada com as permissões necessárias para as verificações pretendidas.
Torne o sistema operativo de destino acessível para SMB/WMI ou SSH.
Crie o tipo de credencial adequado em Managed Risk > Settings > Credentials > Add credential.
Atribua a credencial para uma verificação de vulnerabilidade interna com Scan type: Authenticated e valide o resultado na verificação seguinte.

Prepare os sistemas alvo antes do Sophos Fusion

A preparação é efetuada diretamente no destino Windows, macOS ou Linux e é independente da introdução posterior das credenciais no Sophos Fusion. Mesmo um formulário do Fusion corretamente preenchido não compensa partilhas, serviços ou permissões em falta no destino.

Windows

Para dispositivos e servidores Windows que não sejam controladores de domínio, utilize uma conta local dedicada no grupo de administradores locais. Os controladores de domínio, pelo contrário, exigem um administrador de domínio e devem ser incluídos numa verificação separada com credenciais próprias. Assim, a conta mais privilegiada não é utilizada em servidores membros ou clientes.

Verifique antes de atribuir:

As políticas de segurança como Deny access to this computer from the network e Access this computer from the network, outras políticas locais, proteção de endpoint e IPS/IDS não devem bloquear as verificações de credenciais pretendidas.
Algumas verificações locais requerem o PowerShell 5.0 ou posterior.
O scanner requer acesso SMB e WMI. A firewall do host deve permitir ligações provenientes do endereço IP do dispositivo de verificação do Managed Risk; para File and Printer Sharing, são relevantes as portas TCP 139 e 445. As portas dos outros serviços a verificar também devem estar acessíveis ao scanner.
As partilhas administrativas IPC$, ADMIN$ e C$ deverão estar disponíveis.
Remote Registry deve estar em execução ou poder ser iniciado com as permissões administrativas utilizadas para a verificação.
Nos cenários documentados para contas do Windows, Network access: Sharing and security model for local accounts deve estar definido como Classic - local users authenticate as themselves. Isto aplica-se tanto a uma conta de domínio utilizada para auditorias locais como a uma conta local; iniciar sessão como convidado não é suficiente para verificações de segurança locais.
Para contas locais, o UAC não deve filtrar o token de administrador remoto. As opções documentadas são desativar o UAC ou definir o valor DWORD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy como 1. Efetue uma alteração de segurança deste tipo apenas através do processo interno de gestão de alterações e limite-a aos sistemas afetados.
Para WMI, ative as regras de entrada predefinidas Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) e Windows Management Instrumentation (DCOM-In). Se possível, limite as regras ao endereço IP do dispositivo de verificação.

Não substitua estes requisitos por uma regra de firewall abrangente, aberta a qualquer origem. Se o dispositivo de verificação e um destino estiverem em VLANs diferentes, a especificação da verificação exige que o dispositivo tenha acesso bidirecional completo a todas as portas e protocolos da VLAN de destino. O encaminhamento e as firewalls intermédias devem permitir esse acesso; limite as regras ao dispositivo e aos intervalos de destino pretendidos.

macOS

Os destinos macOS são verificados através de SSH: com um par de chaves ou com credenciais de utilizador e sudo ou su. Para verificações locais completas, a conta de verificação deve ser membro do grupo Administradores e ter Full Disk Access. Com menos direitos, são possíveis verificações individuais, como a determinação do nível de patch, mas não o mesmo nível de verificação. A conta dedicada deve ter o mesmo nome de utilizador em todos os destinos macOS pretendidos; sempre que possível, prefira o acesso por chave às credenciais de utilizador.

Os seguintes requisitos aplicam-se antes da verificação:

Ative Remote Login e autorize a conta de verificação dedicada.
Na definição de sistema Remote Login, ative Allow full disk access for remote users. Além disso, em Privacy & Security, conceda Full Disk Access aos dois processos documentados: /usr/libexec/sshd-keygen-wrapper e /Library/NessusAgent/run/sbin/nessus-service.
Para Kerberos, sshd deve suportar Kerberos, utilizar o método de interação gssapi-with-mic e o DNS reverso deve funcionar corretamente.
O servidor SSH e o scanner devem ter uma cifra comum suportada. blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc e AES-CTR estão documentados. Geralmente, não ative a encriptação desatualizada apenas para verificação; primeiro verifique a opção comum já segura.
Para acesso baseado em chave, coloque a chave pública em authorized_keys na conta dedicada e forneça a chave privada ao scanner apenas de forma protegida.

Linux

Os destinos Linux são também verificados através de SSH: com um par de chaves ou com credenciais de utilizador e sudo ou su. Para obter o maior nível de verificação possível, a conta deve ser capaz de executar comandos com privilégios de root. Uma conta menos privilegiada pode fornecer resultados parciais, mas não cobre totalmente a configuração e as verificações de ficheiros.

Verifique antes de iniciar a verificação:

Configure um utilizador SSH dedicado com exatamente o mesmo nome em todos os destinos pretendidos. Para autenticação apenas por chave, a conta não deve ter uma palavra-passe válida; coloque a chave pública em authorized_keys e mantenha a chave privada protegida no scanner.
Permita a ligação SSH e a elevação de privilégios pretendida a partir da rede do dispositivo de verificação.
Para Kerberos, sshd deve suportar Kerberos, utilizar gssapi-with-mic e ter o DNS reverso a funcionar corretamente.
A configuração da shell da conta de verificação requer uma variável PS1 com pelo menos quatro caracteres. Uma linha de comandos muito curta, como PS1='$ ', pode tornar a verificação significativamente mais lenta.
As mesmas opções documentadas aplicam-se à cifra SSH e ao macOS. Utilize algoritmos comuns seguros existentes e não expanda a configuração do host desnecessariamente.

A preparação geral do host SSH pode suportar tipos de chave mais modernos. No entanto, em Managed Risk > Settings > Credentials, o Public Key aceita atualmente apenas chaves RSA e DSA no formato OpenSSH. Um tipo de chave que não é suportado não pode, portanto, ser utilizável alterando o sistema de destino.

Criar credencial em Sophos Fusion

Em Managed Risk > Settings, abra o separador Credentials e selecione Add credential. Em Create credential selecione primeiro o tipo. A autenticação Plaintext não é suportada.

SNMPv3

SNMPv3 destina-se a dispositivos de rede com SNMP versão 3. Preencha os seguintes campos:

Credential type: SNMPv3.
Credential name: um nome exclusivo, por exemplo snmpv3-core-switches.
Description: uma nota opcional sobre o âmbito de dispositivos pretendido.
Username: o utilizador da conta SNMPv3.
Port: standard 161; alterar apenas se o destino fornecer SNMPv3 numa porta diferente.
Security Level: Authentication and privacy. Esta combinação de autenticação e encriptação é atualmente a única opção.
Authentication algorithm: SHA-256, SHA-384 ou SHA-512 correspondente à configuração de destino.
Authentication password: Palavra-passe de autenticação da conta SNMPv3.
Privacy algorithm: AES-256 ou AES-256C correspondente à configuração de destino.
Privacy password: Palavra-passe de privacidade da conta SNMPv3.
Guarde com Create.

Windows

Para Credential type: Windows, introduza primeiro um Credential name exclusivo e, opcionalmente, um Description. De seguida, selecione uma das três variantes em Authentication method:

Kerberos: introduza Username, Password, Domain, Key Distribution Center (KDC), KDC Port (predefinição 88), KDC Transport (TCP ou UDP) e Realm.
NTLM Hash: introduza Username, Hash e Domain. Trate um hash NTLM como uma palavra-passe e nunca o inclua em materiais de diagnóstico.
Password: introduza Username, Password e, se necessário, o Domain opcional.

Guarde com Create. Para contas locais, o utilizador deve corresponder ao destino; nas verificações de controladores de domínio, utilize as credenciais de administrador de domínio reservadas para esse fim.

SSH para Linux e macOS

Para Credential type: SSH selecione um Credential name exclusivo, opcionalmente um Description e depois o Authentication method:

Kerberos: introduza Username, Key Distribution Center (KDC), KDC Port (predefinição 88), KDC Transport (TCP ou UDP) e Realm.
Password: introduza Username e Password. Selecione Elevate privileges with apenas se a configuração preparada do destino o exigir.
Public Key: introduza Username. Em Private key, utilize Add File para carregar o ficheiro da chave privada ou cole a chave diretamente. Apenas são suportadas chaves RSA e DSA no formato OpenSSH. Para uma chave protegida, introduza também Private key passphrase.

Para Public Key, escolha entre Nothing e sudo em Elevate privileges with. Para sudo, introduza também sudo user e, se necessário, sudo password. A conta e a elevação de privilégios selecionada devem corresponder à configuração preparada no destino.

Opcionalmente, podem ser introduzidos nomes de host, endereços IP ou blocos CIDR em Targets para priorizar esta credencial de chave pública para estes destinos. Separe vários valores com vírgulas ou espaços. Esta priorização não substitui a definição de destinos da verificação nem a seleção de credenciais na verificação.

Guarde com Create.

VMware ESX SOAP API

Este tipo destina-se a hosts VMware ESX/ESXi:

Credential type: VMware ESX SOAP API.
Credential name: um nome exclusivo.
Description: uma nota opcional sobre os hosts pretendidos.
ESX SOAP API Authentication Method: Username and Password. Esta é, atualmente, a única opção.
Username: conta VMware com acesso administrativo ao host ESX/ESXi.
Password: palavra-passe desta conta.
Guarde com Create.

Para auditorias abrangentes, esta conta requer acesso administrativo ao host. A credencial destina-se a ambientes de virtualização VMware, e não a alvos Windows ou SSH nas VMs.

Atribuir uma credencial a uma verificação autenticada

As credenciais guardadas não iniciam uma verificação por si só. Crie uma verificação de vulnerabilidade interna em My Products > Managed Risk > Scans > Internal e configure-a na página Create Vulnerability Scan da seguinte forma:

Selecione o dispositivo de verificação ligado em Select scanner.
Introduza o nome e a descrição em Configure scan details.
Defina Scan type para Authenticated.
Selecione as credenciais adequadas em Select credentials. São possíveis um máximo de dez credenciais por verificação.
Introduza os endereços IP, os intervalos CIDR ou os nomes de host pretendidos em Add scan targets e adicione-os com Add. Confirme individualmente os valores introduzidos com Enter; as listas coladas devem ser separadas por vírgulas.
Defina o dia, a hora e o fuso horário em Schedule the weekly scan e guarde-os no canto superior direito com Save.

Separe as credenciais por sistema operativo, zona de confiança e requisitos de proteção. Em particular, uma credencial de administrador de domínio não deve ser utilizada numa verificação abrangente de clientes Windows comuns. Se forem necessárias mais de dez credenciais, divida o âmbito de destino em verificações claramente delimitadas, em vez de combinar credenciais ou alargar permissões.

Teste as credenciais do Windows antes da próxima verificação

Os testes de credenciais documentados aplicam-se atualmente apenas ao Windows. Execute-os num sistema Windows na mesma sub-rede que o dispositivo de verificação e com exatamente as mesmas credenciais. Isto permite que as condições de rede do scanner sejam replicadas com a maior precisão possível.

Abra um Command Prompt ou PowerShell como administrador. No exemplo, 192.0.2.25 é um endereço de documentação e deve ser substituído pelo IP interno do sistema de destino. LAB-SRV-025\svc_mrisk é um exemplo de conta local; para uma conta de domínio, utilize o formato DOMAIN\User com os seus próprios valores.

Verifique IPC$ e 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 *

Após cada comando, introduza a palavra-passe no prompt oculto. The command completed successfully confirma as credenciais e o respetivo acesso SMB para este teste. O sucesso com ADMIN$ mostra também que a conta tem acesso de partilha administrativa.

Verifique o registo remoto

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

Uma linha de registo de saída para ProgramFilesDir confirma que o Registo Remoto está acessível através da sessão existente. Para The network path was not found, verifique primeiro o serviço, o caminho SMB e a firewall; em Access is denied controla os direitos da conta, o token remoto do UAC e a identidade real utilizada.

Verifique WMI

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

Introduza a palavra-passe apenas no prompt de comando. Um nome de sistema operativo em Name confirma o acesso WMI para este teste. Se wmic não estiver disponível na versão do Windows que está a utilizar, não utilize um comando de substituição não testado. Em vez disso, verifique as regras de firewall WMI e a preparação do host e execute a validação real através da próxima verificação do Managed Risk.

Limpe sempre as sessões

Após o teste, remova ambas as ligações, mesmo que uma etapa intermédia tenha falhado:

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

Em seguida, utilize net use para verificar se já não está listada nenhuma ligação ao destino de teste e feche o terminal administrativo.

Valide o resultado na próxima verificação

Após a próxima execução planeada em Managed Risk > Report History, verifique se o relatório de vulnerabilidade interna foi criado. Os resultados autenticados são normalmente mais detalhados do que os não autenticados. No entanto, um certo número de descobertas não é um critério de sucesso: sistema operativo, portas abertas, software instalado, plugins utilizados e tipo de verificação influenciam o resultado.

Para um teste fiável:

Confirme se Scan type: Authenticated e as credenciais pretendidas estão selecionadas na verificação.
Certifique-se de que os sistemas de destino estão no âmbito da verificação e podem ser alcançados pelo dispositivo de verificação.
Para Windows, verifique primeiro as quatro áreas IPC$, ADMIN$, Remote Registry e WMI.
Para Linux e macOS, verifique a acessibilidade SSH, a chave ou a configuração Kerberos e a elevação de privilégios pretendida.
Verifique os firewalls host e intermédio quanto ao tráfego bloqueado do endereço IP do dispositivo de verificação.
Só depois altere os campos de credenciais e valide-os novamente durante a próxima verificação.

Se os resultados ainda parecerem uma verificação não autenticada ou permanecerem inesperadamente incompletos, envie um pedido à equipa do Managed Risk em Threat Analysis Center > Cases > Create case > Managed Risk service request. Especifique o nome da verificação, a janela de tempo com fuso horário, o nome do scanner, o tipo de destino, o tipo de credencial, os alvos anonimizados afetados, o resultado observado e as verificações já efetuadas. Não anexe palavras-passe, hashes, chaves privadas ou saídas de consola totalmente confidenciais.

Editar ou eliminar credenciais

Para editar em Managed Risk > Settings > Credentials, abra o menu de três pontos na coluna Actions, seleccione Edit, ajuste os campos e guarde com Update. Valide a alteração na próxima verificação agendada.

Antes de eliminar, verifique primeiro todas as definições de verificação que utilizam a credencial. Em seguida, seleccione Delete no mesmo menu de três pontos e apague-o permanentemente na caixa de diálogo com Confirm. A eliminação removerá a credencial de todas as configurações de verificação nas quais foi utilizada e poderá afetar as suas futuras execuções autenticadas. Em seguida, abra cada verificação afetada, verifique a seleção das credenciais restantes e, se necessário, atribua uma credencial de substituição preparada.

A lista de credenciais pode ser recarregada utilizando o símbolo de atualização no canto superior direito. Confirma que a vista de lista foi atualizada, mas não que uma credencial está a funcionar num destino; apenas o teste ou a próxima verificação fornece essa prova.