Sophos Managed Risk: inloggegevens voor geauthenticeerde scans configureren

Tijdens een geauthenticeerde interne kwetsbaarheidsscan meldt de scanner zich aan bij het doelsysteem. Zo kan de scanner lokale bestanden, registervermeldingen, geïnstalleerde software en configuraties controleren die niet zichtbaar zijn bij een scan zonder inloggegevens. Daardoor worden doorgaans meer kwetsbaarheden gevonden. Een niet-geauthenticeerde scan blijft echter nuttig: die benadert beter wat een externe aanvaller zonder account kan bereiken.

De veilige procedure is onderverdeeld in vier stappen:

Bereid een speciaal scanaccount voor met de rechten die nodig zijn voor de beoogde controles.
Maak het doelbesturingssysteem toegankelijk voor SMB/WMI of SSH.
Maak het juiste type inloggegevens aan onder Managed Risk > Settings > Credentials > Add credential.
Wijs de inloggegevens toe aan een interne kwetsbaarheidsscan met Scan type: Authenticated en valideer het resultaat bij de volgende scan.

Doelsystemen voorbereiden voordat u Sophos Fusion gebruikt

De voorbereiding vindt direct op het Windows-, macOS- of Linux-doel plaats en staat los van de latere invoer van de inloggegevens in Sophos Fusion. Zelfs een correct ingevuld Sophos Fusion-formulier kan ontbrekende shares, services of rechten op het doel niet compenseren.

Windows

Gebruik voor Windows-apparaten en -servers die geen domeincontroller zijn een speciaal lokaal account in de lokale beheerdersgroep. Domeincontrollers vereisen daarentegen een domeinbeheerder en horen in een afzonderlijke scan met eigen inloggegevens. Zo wordt het krachtigere account niet gebruikt op lidservers of clients.

Controleer voordat u toewijst:

Beveiligingsbeleid zoals Deny access to this computer from the network en Access this computer from the network, ander lokaal beleid, eindpuntbeveiliging en IPS/IDS mogen de beoogde controles met inloggegevens niet blokkeren.
Voor sommige lokale controles is PowerShell 5.0 of hoger vereist.
De scanner vereist SMB- en WMI-toegang. De hostfirewall moet verbindingen vanaf het IP-adres van het Managed Risk-scanapparaat toestaan; voor File and Printer Sharing zijn TCP-poorten 139 en 445 relevant. Poorten van andere te controleren services moeten eveneens bereikbaar zijn voor de scanner.
De administratieve shares IPC$, ADMIN$ en C$ moeten beschikbaar zijn.
Remote Registry moet actief zijn of gestart kunnen worden met de beheerdersrechten die voor de scan zijn gebruikt.
Voor de gedocumenteerde Windows-accountscenario’s moet Network access: Sharing and security model for local accounts zijn ingesteld op Classic - local users authenticate as themselves. Dit geldt zowel voor een domeinaccount dat voor lokale controles wordt gebruikt als voor een lokaal account; aanmelden als gast volstaat niet voor lokale beveiligingscontroles.
Bij lokale accounts mag UAC het externe beheerderstoken niet filteren. De gedocumenteerde opties zijn UAC uitschakelen of de DWORD-waarde HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy instellen op 1. Voer zo’n beveiligingswijziging alleen uit via het interne wijzigingsproces en beperk deze tot de betrokken systemen.
Voor WMI schakelt u de vooraf gedefinieerde inkomende regels Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) en Windows Management Instrumentation (DCOM-In) in. Beperk de regels indien mogelijk tot het IP-adres van het scanapparaat.

Vervang deze vereisten niet door een brede firewallregel die verkeer uit elke bron toestaat. Als het scanapparaat en een doel zich in verschillende VLAN’s bevinden, moet het apparaat volgens de scanvereisten volledige bidirectionele toegang hebben tot alle poorten en protocollen in het doel-VLAN. Routering en tussenliggende firewalls moeten deze toegang toestaan; beperk de regels daarbij tot het scanapparaat en de beoogde doelbereiken.

macOS

macOS-doelen worden via SSH gecontroleerd, met een sleutelpaar of met inloggegevens van een gebruiker en sudo of su. Voor volledige lokale controles moet het scanaccount lid zijn van de beheerdersgroep en Full Disk Access hebben. Met minder rechten zijn afzonderlijke controles, zoals het bepalen van het patchniveau, nog wel mogelijk, maar niet met dezelfde controlediepte. Het speciale account moet op alle beoogde macOS-doelen dezelfde gebruikersnaam hebben; geef waar mogelijk de voorkeur aan toegang met een sleutel boven gebruikersgegevens.

Vóór de scan gelden de volgende eisen:

Schakel Remote Login in en sta het speciale scanaccount toe.
Schakel in de systeeminstelling Remote Login de optie Allow full disk access for remote users in. Verleen daarnaast in Privacy & Security Full Disk Access aan beide gedocumenteerde processen: /usr/libexec/sshd-keygen-wrapper en /Library/NessusAgent/run/sbin/nessus-service.
Voor Kerberos moet sshd Kerberos ondersteunen, de gssapi-with-mic-interactiemethode gebruiken en omgekeerde DNS moet correct werken.
De SSH-server en scanner moeten een ondersteund versleutelingsalgoritme gemeen hebben. De gedocumenteerde algoritmen zijn blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc en AES-CTR. Schakel niet zonder meer verouderde versleuteling in voor de scan; controleer eerst of er al een veilige gemeenschappelijke optie is.
Voor sleuteltoegang slaat u de openbare sleutel op als authorized_keys in het speciale account en verstrekt u de privésleutel exclusief aan de scanner op een beveiligde manier.

Linux

Linux-doelen worden eveneens via SSH gecontroleerd, met een sleutelpaar of met inloggegevens van een gebruiker en sudo of su. Voor de grootst mogelijke controlediepte moet het account opdrachten met rootrechten kunnen uitvoeren. Een account met minder rechten kan gedeeltelijke resultaten opleveren, maar dekt configuratie- en bestandscontroles niet volledig.

Controleer vóór het scannen:

Maak op alle beoogde doelen een speciale SSH-gebruiker met exact dezelfde naam. Bij uitsluitend sleutelgebaseerde authenticatie mag het account geen geldig wachtwoord hebben; plaats de openbare sleutel in authorized_keys en bewaar de privésleutel beveiligd op de scanner.
Sta de SSH-verbinding en de beoogde privilegeverhoging vanaf het netwerk van het scanapparaat toe.
Voor Kerberos moet sshd Kerberos ondersteunen, gssapi-with-mic gebruiken en omgekeerde DNS correct laten werken.
Voor de shell-configuratie van het scanaccount is een PS1-variabele met minimaal vier tekens vereist. Een zeer korte prompt zoals PS1='$ ' kan de scan aanzienlijk vertragen.
Voor de SSH-codering zijn dezelfde gedocumenteerde opties van toepassing als voor macOS. Gebruik bestaande veilige algemene algoritmen en breid de hostconfiguratie niet onnodig uit.

Algemene SSH-hostvoorbereiding kan modernere sleuteltypen ondersteunen. In Managed Risk > Settings > Credentials accepteert Public Key momenteel echter alleen RSA- en DSA-sleutels in OpenSSH-indeling. Een sleuteltype dat daar niet wordt ondersteund, kan dus niet bruikbaar worden gemaakt door het doelsysteem te wijzigen.

Inloggegevens aanmaken in Sophos Fusion

Open onder Managed Risk > Settings het tabblad Credentials en selecteer Add credential. In Create credential selecteert u eerst het type. Plaintext-verificatie wordt niet ondersteund.

SNMPv3

SNMPv3 is bedoeld voor netwerkapparaten met SNMP versie 3. Vul de volgende velden in:

Credential type: SNMPv3.
Credential name: een unieke naam, bijvoorbeeld snmpv3-core-switches.
Description: optionele opmerking over het beoogde apparaatgebied.
Username: de gebruiker van het SNMPv3-account.
Port: standaard 161; alleen wijzigen als het doel SNMPv3 op een andere poort levert.
Security Level: Authentication and privacy. Deze combinatie van authenticatie en encryptie is momenteel de enige optie.
Authentication algorithm: SHA-256, SHA-384 of SHA-512 passend bij de doelconfiguratie.
Authentication password: SNMPv3-accountverificatiewachtwoord.
Privacy algorithm: AES-256 of AES-256C passend bij de doelconfiguratie.
Privacy password: SNMPv3-accountprivacywachtwoord.
Sla op met Create.

Windows

Voor Credential type: Windows voert u eerst een unieke Credential name in en optioneel een Description. Selecteer dan één van de drie varianten onder Authentication method:

Kerberos: voer Username, Password, Domain, Key Distribution Center (KDC), KDC Port (standaard 88), KDC Transport (TCP of UDP) en Realm in.
NTLM Hash: voer Username, Hash en Domain in. Behandel een NTLM-hash als een wachtwoord en neem deze nooit op in diagnostisch materiaal.
Password: voer Username, Password en indien nodig het optionele Domain in.

Sla op met Create. Voor lokale accounts moet de gebruiker overeenkomen met het doel; gebruik de domeinbeheerdersgegevens die zijn gereserveerd voor scans van domeincontrollers.

SSH voor Linux en macOS

Voor Credential type: SSH selecteert u een unieke Credential name, optioneel een Description en vervolgens de Authentication method:

Kerberos: voer Username, Key Distribution Center (KDC), KDC Port (standaard 88), KDC Transport (TCP of UDP) en Realm in.
Password: voer Username en Password in. Selecteer Elevate privileges with alleen als de voorbereide doelconfiguratie dit vereist.
Public Key: voer Username in. Upload onder Private key met Add File het privésleutelbestand of plak de sleutel rechtstreeks. Alleen RSA- en DSA-sleutels in OpenSSH-indeling worden ondersteund. Voer voor een beveiligde sleutel ook Private key passphrase in.

Voor Public Key kiest u tussen Nothing en sudo onder Elevate privileges with. Voor sudo vult u ook sudo user in en eventueel sudo password. Het account en de gekozen verhoging van rechten moeten overeenkomen met de voorbereide configuratie op het doel.

Optioneel kunt u onder Targets hostnamen, IP-adressen of CIDR-blokken invoeren om deze inloggegevens met openbare sleutel voor die doelen prioriteit te geven. Scheid meerdere waarden met komma’s of spaties. Deze prioritering vervangt noch de doeldefinitie van de scan, noch de selectie van inloggegevens in de scan.

Sla op met Create.

VMware ESX SOAP API

Dit type is bedoeld voor VMware ESX/ESXi-hosts:

Credential type: VMware ESX SOAP API.
Credential name: unieke naam.
Description: optionele opmerking over de beoogde hosts.
ESX SOAP API Authentication Method: Username and Password. Dit is momenteel de enige optie.
Username: VMware-account met beheerderstoegang tot de ESX/ESXi-host.
Password: Wachtwoord van dit account.
Sla op met Create.

Voor uitgebreide controles heeft dit account beheerderstoegang tot de host nodig. Deze inloggegevens zijn bedoeld voor VMware-virtualisatieomgevingen, niet voor Windows- of SSH-doelen binnen de VM’s.

Wijs inloggegevens toe aan een geauthenticeerde scan

Opgeslagen inloggegevens starten niet vanzelf een scan. Maak een interne kwetsbaarheidsscan onder My Products > Managed Risk > Scans > Internal en configureer deze als volgt op de Create Vulnerability Scan-pagina:

Selecteer het aangesloten scanapparaat onder Select scanner.
Voer naam en beschrijving in onder Configure scan details.
Stel Scan type in op Authenticated.
Selecteer de juiste inloggegevens onder Select credentials. Per scan zijn maximaal tien inloggegevens mogelijk.
Voer de beoogde IP-adressen, CIDR-bereiken of hostnamen in onder Add scan targets en neem deze over met Add. Bevestig afzonderlijk ingevoerde waarden met Enter; ingeplakte lijsten moeten door komma’s worden gescheiden.
Stel de dag, tijd en tijdzone in onder Schedule the weekly scan en sla deze rechtsboven op met Save.

Scheid inloggegevens op basis van besturingssysteem, vertrouwenszone en beveiligingsvereiste. Inloggegevens van een domeinbeheerder horen met name niet thuis in een brede scan van gewone Windows-clients. Als er meer dan tien sets inloggegevens nodig zijn, verdeelt u het doelbereik over duidelijk afgebakende scans in plaats van inloggegevens te combineren of rechten uit te breiden.

Test Windows-inloggegevens vóór de volgende scan

De beschreven tests van inloggegevens gelden momenteel alleen voor Windows. Voer ze uit vanaf een Windows-systeem in hetzelfde subnet als het scanapparaat en met exact dezelfde inloggegevens. Zo worden de netwerkomstandigheden van de scanner zo nauwkeurig mogelijk nagebootst.

Open een Command Prompt of PowerShell als beheerder. In het voorbeeld is 192.0.2.25 een documentatieadres en moet worden vervangen door het interne IP-adres van het doelsysteem. LAB-SRV-025\svc_mrisk is een lokaal voorbeeldaccount; gebruik voor een domeinaccount de notatie DOMAIN\User met uw eigen waarden.

Controleer IPC$ en 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 *

Voer na elke opdracht het wachtwoord in bij de verborgen prompt. The command completed successfully bevestigt voor deze test de inloggegevens en de betreffende SMB-toegang. Succes met ADMIN$ laat ook zien dat het account beheerderstoegang heeft tot delen.

Controleer het externe register

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

Een uitvoerregisterregel voor ProgramFilesDir bevestigt dat Remote Registry toegankelijk is via de bestaande sessie. Controleer voor The network path was not found eerst de service, het SMB-pad en de firewall; controleer bij Access is denied de accountrechten, het externe UAC-token en de identiteit die daadwerkelijk wordt gebruikt.

Controleer WMI

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

Voer het wachtwoord alleen in via de opdrachtprompt. Een besturingssysteemnaam onder Name bevestigt WMI-toegang voor deze test. Als wmic niet beschikbaar is in de versie van Windows die u gebruikt, gebruik dan geen ongeteste vervangingsopdracht. Controleer in plaats daarvan de WMI-firewallregels en hostvoorbereiding en voer de daadwerkelijke validatie uit via de volgende Managed Risk-scan.

Ruim sessies altijd op

Verwijder na het testen beide verbindingen, ook als een tussenstap mislukt:

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

Gebruik vervolgens net use om te controleren of er geen verbinding meer is met het testdoel en sluit de administratieve terminal.

Valideer het resultaat bij de volgende scan

Controleer na de volgende geplande run onder Managed Risk > Report History of de interne kwetsbaarheidsrapportage is aangemaakt. Geauthenticeerde resultaten zijn doorgaans gedetailleerder dan niet-geauthenticeerde resultaten. Een aantal bevindingen is echter geen criterium voor succes: besturingssysteem, open poorten, geïnstalleerde software, gebruikte plug-ins en scantype beïnvloeden het resultaat.

Voor een betrouwbare test:

Bevestig dat Scan type: Authenticated en de beoogde inloggegevens in de scan zijn geselecteerd.
Zorg ervoor dat de doelsystemen zich binnen het scanbereik bevinden en door het scanapparaat kunnen worden bereikt.
Controleer voor Windows eerst de vier gebieden IPC$, ADMIN$, Remote Registry en WMI.
Controleer voor Linux en macOS de SSH-toegankelijkheid, sleutel- of Kerberos-configuratie en de beoogde uitbreiding van bevoegdheden.
Controleer de host- en tussenfirewalls op geblokkeerd verkeer van het IP-adres van het scanapparaat.
Wijzig pas daarna de velden voor inloggegevens en valideer ze opnieuw tijdens de volgende scan.

Als de resultaten nog steeds een niet-geauthenticeerde scan lijken te zijn of onverwacht onvolledig blijven, dien dan een verzoek in bij het Managed Risk-team op Threat Analysis Center > Cases > Create case > Managed Risk service request. Specificeer de scannaam, het tijdvenster met tijdzone, de scannernaam, het doeltype, het type inloggegevens, de betrokken geanonimiseerde doelen, het waargenomen resultaat en de reeds uitgevoerde controles. Voeg geen wachtwoorden, hashes, privésleutels of volledig gevoelige console-uitvoer toe.

Bewerk of verwijder inloggegevens

Om onder Managed Risk > Settings > Credentials te bewerken, opent u het menu met drie stippen in de kolom Actions, selecteert u Edit, past u de velden aan en slaat u op met Update. Valideer de wijziging bij de volgende geplande scan.

Controleer vóór verwijdering eerst alle scanconfiguraties die de inloggegevens gebruiken. Selecteer vervolgens Delete in hetzelfde driepuntsmenu en verwijder ze definitief met Confirm in het dialoogvenster. Door de verwijdering verdwijnen de inloggegevens uit alle scanconfiguraties waarin ze werden gebruikt; toekomstige geauthenticeerde uitvoeringen kunnen hierdoor worden beïnvloed. Open daarna elke betrokken scan, controleer de resterende selectie en wijs zo nodig voorbereide vervangende inloggegevens toe.

Met het verversingssymbool rechtsboven kunt u de lijst met inloggegevens opnieuw laden. Daarmee bevestigt u dat de lijstweergave is bijgewerkt, maar niet dat de inloggegevens op een doel werken; alleen de test of de volgende scan levert dat bewijs.