Sophos Managed Risk: configurare le credenziali per le scansioni autenticate

Durante una scansione interna autenticata delle vulnerabilità, lo scanner accede al sistema di destinazione. Può così esaminare file locali, voci del Registro di sistema, software installato e configurazioni che non sono visibili a una scansione senza credenziali. Di norma, quindi, rileva un maggior numero di vulnerabilità. Una scansione non autenticata resta comunque utile, poiché rispecchia meglio ciò a cui potrebbe accedere un aggressore esterno privo di account.

La procedura sicura si articola in quattro passaggi:

Preparare un account di scansione dedicato con le autorizzazioni necessarie per i controlli previsti.
Rendere il sistema operativo di destinazione accessibile tramite SMB/WMI o SSH.
Creare il tipo di credenziale appropriato in Managed Risk > Settings > Credentials > Add credential.
Assegnare la credenziale a una scansione interna delle vulnerabilità con Scan type: Authenticated e convalidare il risultato alla scansione successiva.

Preparare i sistemi di destinazione prima di utilizzare Sophos Fusion

La preparazione viene effettuata direttamente sul sistema Windows, macOS o Linux di destinazione ed è distinta dal successivo inserimento delle credenziali in Sophos Fusion. Anche un modulo Fusion compilato correttamente non può sopperire alla mancanza di condivisioni, servizi o autorizzazioni sul sistema di destinazione.

Windows

Per gli endpoint e i server Windows diversi dai controller di dominio, utilizzare un account locale dedicato appartenente al gruppo Administrators locale. I controller di dominio richiedono invece un amministratore di dominio e devono essere inclusi in una scansione separata con credenziali proprie. In questo modo, l’account con privilegi più elevati non viene utilizzato sui server membri o sui client.

Prima dell’assegnazione, verificare quanto segue:

I criteri di sicurezza come Deny access to this computer from the network e Access this computer from the network, gli altri criteri locali, la protezione degli endpoint e i sistemi IPS/IDS non devono bloccare i controlli previsti con le credenziali.
Alcuni controlli locali richiedono PowerShell 5.0 o versioni successive.
Lo scanner richiede l’accesso SMB e WMI. Il firewall dell’host deve consentire le connessioni provenienti dall’indirizzo IP dell’appliance di scansione Managed Risk; per File and Printer Sharing sono necessarie le porte TCP 139 e 445. Anche le porte degli altri servizi da controllare devono essere raggiungibili dallo scanner.
Le condivisioni amministrative IPC$, ADMIN$ e C$ devono essere disponibili.
Remote Registry deve essere in esecuzione oppure deve poter essere avviato con le autorizzazioni amministrative utilizzate per la scansione.
Negli scenari documentati per gli account Windows, Network access: Sharing and security model for local accounts deve essere impostato su Classic - local users authenticate as themselves. Ciò vale sia per un account di dominio utilizzato per i controlli locali, sia per un account locale; l’accesso come guest non è sufficiente per i controlli di sicurezza locali.
Per gli account locali, UAC non deve filtrare il token amministratore remoto. Le opzioni documentate prevedono la disattivazione di UAC oppure l’impostazione su 1 del valore DWORD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. Apportare una simile modifica alla sicurezza solo nell’ambito della procedura interna di gestione delle modifiche e limitarla ai sistemi interessati.
Per WMI, abilitare le regole in ingresso predefinite Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) e Windows Management Instrumentation (DCOM-In). Se possibile, limitare le regole all’indirizzo IP dell’appliance di scansione.

Non sostituire questi requisiti con una regola firewall generica aperta a qualsiasi origine. Se l’appliance di scansione e il sistema di destinazione si trovano in VLAN diverse, le specifiche della scansione richiedono che l’appliance disponga di accesso bidirezionale completo a tutte le porte e a tutti i protocolli della VLAN di destinazione. Il routing e i firewall intermedi devono consentire tale accesso; limitare comunque le regole all’appliance e agli intervalli di destinazione previsti.

macOS

I sistemi macOS vengono controllati tramite SSH, utilizzando una coppia di chiavi oppure le credenziali utente con sudo o su. Per eseguire controlli locali completi, l’account di scansione deve appartenere al gruppo degli amministratori e disporre di Full Disk Access. Con autorizzazioni inferiori è comunque possibile eseguire alcuni controlli, ad esempio determinare il livello delle patch, ma non ottenere la stessa profondità di analisi. L’account dedicato deve avere lo stesso nome utente su tutti i sistemi macOS previsti; quando possibile, è preferibile utilizzare l’accesso tramite chiave anziché le credenziali utente.

Prima della scansione devono essere soddisfatti i seguenti prerequisiti:

Abilitare Remote Login e autorizzare l’account di scansione dedicato.
Nell’impostazione di sistema Remote Login, attivare Allow full disk access for remote users. Concedere inoltre Full Disk Access in Privacy & Security a entrambi i processi documentati: /usr/libexec/sshd-keygen-wrapper e /Library/NessusAgent/run/sbin/nessus-service.
Per Kerberos, sshd deve supportare Kerberos, utilizzare il metodo di interazione gssapi-with-mic e disporre di una risoluzione DNS inversa funzionante.
Il server SSH e lo scanner devono avere in comune un algoritmo di cifratura supportato. Quelli documentati sono blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc e AES-CTR. Non abilitare indiscriminatamente metodi di cifratura obsoleti solo per la scansione; verificare prima se esiste già un’opzione comune sicura.
Per l’accesso tramite chiave, inserire la chiave pubblica in authorized_keys per l’account dedicato e fornire la chiave privata allo scanner esclusivamente in forma protetta.

Linux

Anche i sistemi Linux vengono controllati tramite SSH, utilizzando una coppia di chiavi oppure le credenziali utente con sudo o su. Per ottenere la massima profondità di analisi, l’account deve poter eseguire comandi con privilegi root. Un account con privilegi inferiori può fornire risultati parziali, ma non consente di eseguire tutti i controlli su configurazioni e file.

Prima della scansione, verificare quanto segue:

Creare un utente SSH dedicato con esattamente lo stesso nome su tutti i sistemi previsti. Per l’autenticazione esclusivamente tramite chiave, l’account non deve avere una password valida; inserire la chiave pubblica in authorized_keys e conservare la chiave privata in modo protetto sullo scanner.
Consentire la connessione SSH e l’elevazione dei privilegi prevista dalla rete dell’appliance di scansione.
Per Kerberos, sshd deve supportare Kerberos, utilizzare gssapi-with-mic e disporre di una risoluzione DNS inversa funzionante.
La configurazione della shell dell’account di scansione deve includere una variabile PS1 di almeno quattro caratteri. Un prompt molto breve, come PS1='$ ', può rallentare notevolmente la scansione.
Le opzioni di cifratura SSH documentate sono le stesse indicate per macOS. Utilizzare algoritmi sicuri già supportati da entrambi i sistemi e non ampliare inutilmente la configurazione dell’host.

La preparazione generale dell’host SSH può supportare tipi di chiave più moderni. In Managed Risk > Settings > Credentials, tuttavia, Public Key accetta attualmente solo chiavi RSA e DSA in formato OpenSSH. Un tipo di chiave non supportato in questa sezione non può quindi essere reso utilizzabile modificando il sistema di destinazione.

Creare una credenziale in Sophos Fusion

In Managed Risk > Settings, aprire la scheda Credentials e selezionare Add credential. In Create credential, selezionare innanzitutto il tipo. L’autenticazione Plaintext non è supportata.

SNMPv3

SNMPv3 è destinato ai dispositivi di rete che utilizzano SNMP versione 3. Compilare i seguenti campi:

Credential type: SNMPv3.
Credential name: un nome univoco, ad esempio snmpv3-core-switches.
Description: una nota facoltativa sull’ambito di dispositivi previsto.
Username: l’utente dell’account SNMPv3.
Port: il valore predefinito è 161; modificarlo solo se il sistema di destinazione rende disponibile SNMPv3 su un’altra porta.
Security Level: Authentication and privacy. Questa combinazione di autenticazione e crittografia è attualmente l’unica opzione.
Authentication algorithm: SHA-256, SHA-384 o SHA-512, in base alla configurazione del sistema di destinazione.
Authentication password: la password di autenticazione dell’account SNMPv3.
Privacy algorithm: AES-256 o AES-256C, in base alla configurazione del sistema di destinazione.
Privacy password: la password di privacy dell’account SNMPv3.
Selezionare Create per salvare.

Windows

Per Credential type: Windows, inserire innanzitutto un Credential name univoco e, facoltativamente, una Description. Quindi selezionare una delle tre opzioni disponibili in Authentication method:

Kerberos: inserire Username, Password, Domain, Key Distribution Center (KDC), KDC Port (valore predefinito 88), KDC Transport (TCP o UDP) e Realm.
NTLM Hash: inserire Username, Hash e Domain. Trattare un hash NTLM come una password e non includerlo mai nel materiale diagnostico.
Password: inserire Username, Password e, se necessario, il campo facoltativo Domain.

Selezionare Create per salvare. Per gli account locali, l’utente deve corrispondere al sistema di destinazione interessato; per le scansioni dei controller di dominio, utilizzare le credenziali di amministratore di dominio riservate a tale scopo.

SSH per Linux e macOS

Per Credential type: SSH, inserire un Credential name univoco, facoltativamente una Description, quindi selezionare il metodo in Authentication method:

Kerberos: inserire Username, Key Distribution Center (KDC), KDC Port (valore predefinito 88), KDC Transport (TCP o UDP) e Realm.
Password: inserire Username e Password. Selezionare Elevate privileges with solo se richiesto dalla configurazione predisposta sul sistema di destinazione.
Public Key: inserire Username. In Private key, utilizzare Add File per caricare il file della chiave privata oppure incollare direttamente la chiave. Sono supportate solo chiavi RSA e DSA in formato OpenSSH. Per una chiave protetta, inserire anche la Private key passphrase.

Per Public Key, selezionare Nothing o sudo in Elevate privileges with. Se si seleziona sudo, inserire anche sudo user e, se necessario, sudo password. L’account e il metodo di elevazione selezionato devono corrispondere alla configurazione predisposta sul sistema di destinazione.

Facoltativamente, in Targets è possibile inserire nomi host, indirizzi IP o blocchi CIDR per assegnare priorità a questa credenziale con chiave pubblica per tali destinazioni. Separare più valori con virgole o spazi. Questa assegnazione di priorità non sostituisce né la definizione delle destinazioni della scansione, né la selezione delle credenziali nella scansione.

Selezionare Create per salvare.

VMware ESX SOAP API

Questo tipo è destinato agli host VMware ESX/ESXi:

Credential type: VMware ESX SOAP API.
Credential name: un nome univoco.
Description: una nota facoltativa sugli host previsti.
ESX SOAP API Authentication Method: Username and Password. Questa è attualmente l’unica opzione.
Username: un account VMware con accesso amministrativo all’host ESX/ESXi.
Password: la password dell’account.
Selezionare Create per salvare.

Per controlli completi, l’account deve disporre dell’accesso amministrativo all’host. La credenziale è destinata agli ambienti di virtualizzazione VMware, non ai sistemi Windows o SSH presenti all’interno delle macchine virtuali.

Assegnare la credenziale a una scansione autenticata

Le credenziali salvate non avviano automaticamente una scansione. In My Products > Managed Risk > Scans > Internal, creare una scansione interna delle vulnerabilità e configurarla nella pagina Create Vulnerability Scan come segue:

In Select scanner, selezionare l’appliance di scansione connessa.
In Configure scan details, inserire un nome e una descrizione.
Impostare Scan type su Authenticated.
In Select credentials, selezionare le credenziali appropriate. È possibile utilizzare al massimo dieci credenziali per scansione.
In Add scan targets, inserire gli indirizzi IP, gli intervalli CIDR o i nomi host previsti e selezionare Add. Confermare con Invio ogni valore immesso singolarmente; gli elenchi incollati devono essere separati da virgole.
In Schedule the weekly scan, impostare il giorno, l’ora e il fuso orario, quindi selezionare Save nell’angolo in alto a destra.

Separare le credenziali in base al sistema operativo, all’area di attendibilità e ai requisiti di protezione. In particolare, una credenziale di amministratore di dominio non deve essere inclusa in un’ampia scansione di normali client Windows. Se sono necessarie più di dieci credenziali, suddividere l’ambito di destinazione in scansioni ben definite, anziché accorpare le credenziali o estendere le autorizzazioni.

Testare la credenziale Windows prima della scansione successiva

I test delle credenziali qui documentati si applicano attualmente solo a Windows. Eseguirli da un sistema Windows situato nella stessa sottorete dell’appliance di scansione e utilizzando esattamente le stesse credenziali. In questo modo si riproducono il più fedelmente possibile le condizioni di rete dello scanner.

Aprire Command Prompt o PowerShell come amministratore. Nell’esempio, 192.0.2.25 è un indirizzo riservato alla documentazione e deve essere sostituito con l’indirizzo IP interno del sistema di destinazione. LAB-SRV-025\svc_mrisk è un esempio di account locale; per un account di dominio, utilizzare invece il proprio formato DOMAIN\User.

Verificare 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 *

Dopo ciascun comando, inserire la password quando viene richiesto senza che sia visualizzata. The command completed successfully conferma, ai fini di questo test, la validità delle credenziali e l’accesso alla rispettiva condivisione SMB. L’esito positivo per ADMIN$ indica inoltre che l’account può accedere alle condivisioni amministrative.

Verificare Remote Registry

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

La visualizzazione di una riga del Registro relativa a ProgramFilesDir conferma che Remote Registry è raggiungibile tramite la sessione esistente. In caso di The network path was not found, controllare innanzitutto il servizio, il percorso SMB e il firewall; in caso di Access is denied, verificare le autorizzazioni dell’account, il token remoto UAC e l’identità effettivamente utilizzata.

Verificare WMI

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

Inserire la password solo quando viene richiesta. La visualizzazione del nome del sistema operativo sotto Name conferma l’accesso WMI per questo test. Se wmic non è disponibile nella versione di Windows in uso, non ricorrere a un comando alternativo non testato. Controllare invece le regole firewall WMI e la preparazione dell’host, quindi eseguire la convalida effettiva con la scansione Managed Risk successiva.

Chiudere sempre le sessioni

Dopo il test, rimuovere entrambe le connessioni, anche se uno dei passaggi intermedi non è riuscito:

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

Utilizzare quindi net use per verificare che non sia più elencata alcuna connessione al sistema di test e chiudere il terminale amministrativo.

Convalidare il risultato nella scansione successiva

Dopo l’esecuzione pianificata successiva, verificare in Managed Risk > Report History che sia stato creato il report interno sulle vulnerabilità. In genere, i risultati autenticati sono più dettagliati di quelli non autenticati. Un determinato numero di rilevamenti non costituisce tuttavia un criterio di successo: il sistema operativo, le porte aperte, il software installato, i plugin utilizzati e il tipo di scansione influiscono tutti sul risultato.

Per una verifica attendibile:

Confermare che nella scansione siano selezionati Scan type: Authenticated e le credenziali previste.
Assicurarsi che i sistemi di destinazione rientrino nell’ambito della scansione e siano raggiungibili dall’appliance di scansione.
Per Windows, verificare innanzitutto le quattro aree IPC$, ADMIN$, Remote Registry e WMI.
Per Linux e macOS, verificare la raggiungibilità tramite SSH, la configurazione delle chiavi o di Kerberos e l’elevazione dei privilegi prevista.
Controllare se i firewall degli host e quelli intermedi bloccano il traffico proveniente dall’indirizzo IP dell’appliance di scansione.
Solo dopo questi controlli, modificare i campi delle credenziali e convalidarli nuovamente alla scansione successiva.

Se i risultati continuano ad apparire come quelli di una scansione non autenticata o restano inaspettatamente incompleti, creare una richiesta per il team Managed Risk in Threat Analysis Center > Cases > Create case > Managed Risk service request. Indicare il nome della scansione, l’intervallo temporale con il fuso orario, il nome dello scanner, il tipo di destinazione, il tipo di credenziale, le destinazioni interessate in forma anonima, il risultato osservato e i controlli già eseguiti. Non allegare password, hash, chiavi private o output completi della console contenenti dati sensibili.

Modificare o eliminare le credenziali

Per modificare una credenziale, accedere a Managed Risk > Settings > Credentials, aprire il menu con i tre puntini nella colonna Actions, selezionare Edit, modificare i campi e selezionare Update per salvare. Convalidare la modifica alla scansione prevista successiva.

Prima di eliminare una credenziale, controllare tutte le configurazioni di scansione che la utilizzano. Quindi selezionare Delete dallo stesso menu con i tre puntini e confermare l’eliminazione definitiva selezionando Confirm nella finestra di dialogo. L’eliminazione rimuove la credenziale da tutte le configurazioni di scansione in cui era utilizzata e può compromettere le future esecuzioni autenticate. Aprire quindi ogni scansione interessata, controllare le credenziali ancora selezionate e, se necessario, assegnare una credenziale sostitutiva già predisposta.

L’icona di aggiornamento nell’angolo in alto a destra ricarica l’elenco delle credenziali. Conferma che la visualizzazione dell’elenco è stata aggiornata, ma non che una credenziale funzioni su un sistema di destinazione; tale conferma può essere fornita solo dal test o dalla scansione successiva.