Sophos Managed Risk: konfigurera autentiseringsuppgifter för autentiserade skanningar

Vid en autentiserad intern sårbarhetsskanning loggar skannern in på målsystemet. Då kan den kontrollera lokala filer, registerposter, installerad programvara och konfigurationer som inte är synliga vid en skanning utan autentiseringsuppgifter. Därför hittar den vanligtvis fler sårbarheter. En oautentiserad skanning är ändå användbar eftersom den bättre visar vad en extern angripare utan konto kan komma åt.

Det säkra förfarandet är uppdelat i fyra steg:

Förbered ett dedikerat skanningskonto med de behörigheter som krävs för de avsedda kontrollerna.
Gör måloperativsystemet tillgängligt för SMB/WMI eller SSH.
Skapa lämplig autentiseringstyp under Managed Risk > Settings > Credentials > Add credential.
Tilldela autentiseringsuppgifterna till en intern sårbarhetsskanning med Scan type: Authenticated och validera resultatet i nästa skanning.

Förbered målsystem före Sophos Fusion

Förberedelserna görs direkt på Windows-, macOS- eller Linux-målet och är separata från den senare inmatningen av autentiseringsuppgifter i Sophos Fusion. Inte ens ett korrekt ifyllt Fusion-formulär kan kompensera för saknade resursdelningar, tjänster eller behörigheter på målet.

Windows

För Windows-enheter och servrar som inte är domänkontrollanter använder du ett dedikerat lokalt konto i den lokala administratörsgruppen. Domänkontrollanter kräver däremot en domänadministratör och ska ingå i en separat skanning med egna autentiseringsuppgifter. Därmed används inte det mer privilegierade kontot på medlemsservrar eller klienter.

Kontrollera innan du tilldelar:

Säkerhetspolicyer som Deny access to this computer from the network och Access this computer from the network, andra lokala policyer, slutpunktsskydd och IPS/IDS får inte blockera de avsedda behörighetskontrollerna.
Vissa lokala kontroller kräver PowerShell 5.0 eller senare.
Skannern kräver SMB- och WMI-åtkomst. Värdbrandväggen måste tillåta anslutningar från IP-adressen för Managed Risk-skanningsenheten. TCP-portarna 139 och 445 används för File and Printer Sharing. Portar för andra tjänster som ska kontrolleras måste också kunna nås från skannern.
De administrativa resursdelningarna IPC$, ADMIN$ och C$ måste vara tillgängliga.
Remote Registry måste vara igång eller kunna startas med de administrativa rättigheter som används för skanningen.
För de dokumenterade Windows-kontoscenarierna måste Network access: Sharing and security model for local accounts vara inställt på Classic - local users authenticate as themselves. Detta gäller både ett domänkonto som används för lokala kontroller och ett lokalt konto. Inloggning som gäst räcker inte för lokala säkerhetskontroller.
För lokala konton får UAC inte filtrera fjärradministratörstoken. De dokumenterade alternativen är att inaktivera UAC eller ställa in DWORD-värdet HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy på 1. Genomför endast en sådan säkerhetsändring enligt den interna ändringsprocessen och begränsa den till de berörda systemen.
För WMI aktivera de fördefinierade inkommande reglerna Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) och Windows Management Instrumentation (DCOM-In). Om möjligt, begränsa reglerna till IP-adressen för skanningsenheten.

Ersätt inte dessa krav med en bred brandväggsregel som är öppen för valfri källa. Om skanningsenheten och ett mål finns i olika VLAN kräver skanningsspecifikationen att enheten har full dubbelriktad åtkomst till alla portar och protokoll i mål-VLAN:et. Routing och mellanliggande brandväggar måste tillåta denna åtkomst. Begränsa reglerna till skanningsenheten och de avsedda målområdena.

macOS

macOS-mål kontrolleras via SSH, antingen med ett nyckelpar eller med användaruppgifter och sudo eller su. För fullständiga lokala kontroller måste skanningskontot tillhöra administratörsgruppen och ha Full Disk Access. Med färre behörigheter går det fortfarande att utföra enskilda kontroller, till exempel att fastställa korrigeringsnivån, men inte med samma kontrolldjup. Det dedikerade kontot måste ha samma användarnamn på alla avsedda macOS-mål. Använd om möjligt nyckelbaserad åtkomst i stället för användaruppgifter.

Följande krav gäller före skanningen:

Aktivera Remote Login och tillåt det dedikerade skanningskontot.
Aktivera Allow full disk access for remote users i systeminställningen Remote Login. Ge dessutom Full Disk Access under Privacy & Security till båda de dokumenterade processerna: /usr/libexec/sshd-keygen-wrapper och /Library/NessusAgent/run/sbin/nessus-service.
För Kerberos måste sshd stödja Kerberos, använda interaktionsmetoden gssapi-with-mic och omvänd DNS måste fungera korrekt.
SSH-servern och skannern måste ha stöd för minst ett gemensamt chiffer. De dokumenterade alternativen är blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc och AES-CTR. Aktivera inte föråldrad kryptering generellt enbart för skanningen. Kontrollera först om det redan finns ett säkert gemensamt alternativ.
För nyckelåtkomst, lagra den offentliga nyckeln som authorized_keys i det dedikerade kontot och tillhandahåll den privata nyckeln exklusivt till skannern på ett skyddat sätt.

Linux

Linux-mål kontrolleras också via SSH, med ett nyckelpar eller med användaruppgifter och sudo eller su. För största möjliga kontrolldjup måste kontot kunna köra kommandon med root-behörighet. Ett mindre privilegierat konto kan ge partiella resultat men täcker inte helt konfigurations- och filkontroller.

Kontrollera före skanning:

Skapa en dedikerad SSH-användare med exakt samma namn på alla avsedda mål. Om du bara loggar in med en nyckel måste kontot hanteras utan ett giltigt lösenord; den offentliga nyckeln är i authorized_keys, den privata nyckeln förblir skyddad i skannern.
Aktivera SSH-anslutning och avsedd höjning av privilegier från skanningsapparatens nätverk.
För Kerberos måste sshd stödja Kerberos och använda gssapi-with-mic, och omvänd DNS måste fungera korrekt.
Skalkonfigurationen för skanningskontot kräver en PS1-variabel med minst fyra tecken. En mycket kort kommandoprompt, till exempel PS1='$ ', kan göra skanningen betydligt långsammare.
Samma dokumenterade alternativ gäller för SSH-chifferet som för macOS. Använd befintliga säkra vanliga algoritmer och utöka inte värdkonfigurationen i onödan.

Allmän SSH-värdförberedelse kan stödja mer moderna nyckeltyper. Men i Managed Risk > Settings > Credentials accepterar Public Key för närvarande endast RSA- och DSA-nycklar i OpenSSH-format. En nyckeltyp som inte stöds där kan därför inte göras användbar genom att ändra målsystemet.

Skapa autentiseringsuppgifter i Sophos Fusion

Under Managed Risk > Settings öppnar du fliken Credentials och väljer Add credential. I Create credential väljer du först typen. Plaintext-autentisering stöds inte.

SNMPv3

SNMPv3 är avsedd för nätverksenheter med SNMP version 3. Fyll i följande fält:

Credential type: SNMPv3.
Credential name: ett unikt namn, till exempel snmpv3-core-switches.
Description: valfri notering om det avsedda enhetsområdet.
Username: användaren för SNMPv3-kontot.
Port: som standard 161; ändra endast om målet tillhandahåller SNMPv3 på en annan port.
Security Level: Authentication and privacy. Denna kombination av autentisering och kryptering är för närvarande det enda alternativet.
Authentication algorithm: SHA-256, SHA-384 eller SHA-512 för att matcha målkonfigurationen.
Authentication password: SNMPv3-kontoautentiseringslösenord.
Privacy algorithm: AES-256 eller AES-256C för att matcha målkonfigurationen.
Privacy password: Sekretesslösenord för SNMPv3-kontot.
Spara med Create.

Windows

För Credential type: Windows anger du först ett unikt Credential name och eventuellt ett Description. Välj sedan en av de tre varianterna under Authentication method:

Kerberos: ange Username, Password, Domain, Key Distribution Center (KDC), KDC Port (standard 88), KDC Transport (TCP eller UDP) och Realm.
NTLM Hash: ange Username, Hash och Domain. Behandla en NTLM-hash som ett lösenord och ta aldrig med den i diagnostiskt material.
Password: ange Username, Password och vid behov det valfria fältet Domain.

Spara med Create. För lokala konton måste användaren motsvara det aktuella målet. Använd de domänadministratörsuppgifter som har reserverats för skanningar av domänkontrollanter.

SSH för Linux och macOS

För Credential type: SSH anger du ett unikt Credential name, eventuellt en Description, och väljer sedan Authentication method:

Kerberos: ange Username, Key Distribution Center (KDC), KDC Port (standard 88), KDC Transport (TCP eller UDP) och Realm.
Password: Ange Username och Password. Välj endast Elevate privileges with om den förberedda målkonfigurationen kräver det.
Public Key: Ange Username. Under Private key använder du Add File för att ladda upp den privata nyckelfilen eller klistrar in nyckeln direkt. Endast RSA- och DSA-nycklar i OpenSSH-format stöds. För en skyddad nyckel anger du även Private key passphrase.

Vid Public Key under Elevate privileges with väljer du mellan Nothing och sudo. För sudo anger du även sudo user och vid behov sudo password. Kontot och den valda behörighetshöjningen måste stämma överens med den förberedda konfigurationen på målet.

Valfritt kan värdnamn, IP-adresser eller CIDR-block anges under Targets för att prioritera denna publika nyckel för dessa mål. Separera flera värden med kommatecken eller mellanslag. Denna prioritering ersätter varken måldefinitionen för skanningen eller valet av autentiseringsuppgifter i skanningen.

Spara med Create.

VMware ESX SOAP API

Denna typ är avsedd för VMware ESX/ESXi-värdar:

Credential type: VMware ESX SOAP API.
Credential name: unikt namn.
Description: valfri notering om de avsedda värdarna.
ESX SOAP API Authentication Method: Username and Password. Detta är för närvarande det enda alternativet.
Username: VMware-konto med administrativ åtkomst till ESX/ESXi-värden.
Password: Lösenordet för detta konto.
Spara med Create.

För omfattande revisioner kräver detta konto administrativ åtkomst till värden. Inloggningsuppgifterna är avsedda för VMware-virtualiseringsmiljöer, inte Windows- eller SSH-mål inom virtuella datorer.

Tilldela autentiseringsuppgifter till en autentiserad skanning

Sparade autentiseringsuppgifter startar inte en skanning av sig själva. Skapa en intern sårbarhetsskanning under My Products > Managed Risk > Scans > Internal och konfigurera den på sidan Create Vulnerability Scan enligt följande:

Välj den anslutna skanningsapparaten under Select scanner.
Ange namn och beskrivning under Configure scan details.
Ställ Scan type på Authenticated.
Välj lämpliga autentiseringsuppgifter under Select credentials. Högst tio uppsättningar autentiseringsuppgifter kan användas per skanning.
Ange de avsedda IP-adresserna, CIDR-intervallen eller värdnamnen under Add scan targets och acceptera dem med Add. Bekräfta individuellt registrerade värden med Enter; Infogade listor måste avgränsas med kommatecken.
Ställ in dag, tid och tidszon under Schedule the weekly scan och spara med Save uppe till höger.

Separera autentiseringsuppgifter efter operativsystem, förtroendezon och skyddskrav. Autentiseringsuppgifter för en domänadministratör ska i synnerhet inte användas i en bred skanning av vanliga Windows-klienter. Om fler än tio uppsättningar krävs delar du upp målområdet i tydligt avgränsade skanningar i stället för att kombinera autentiseringsuppgifter eller utöka behörigheter.

Testa Windows-uppgifterna innan nästa skanning

De dokumenterade testerna av autentiseringsuppgifter gäller för närvarande endast Windows. Kör dem från ett Windows-system i samma undernät som skanningsenheten och med exakt samma autentiseringsuppgifter. Detta gör att skannerns nätverksförhållanden kan replikeras så exakt som möjligt.

Öppna en Command Prompt eller PowerShell som administratör. I exemplet är 192.0.2.25 en dokumentationsadress och måste ersättas av målsystemets interna IP. LAB-SRV-025\svc_mrisk är ett exempel på ett lokalt konto. För ett domänkonto använder du formatet DOMAIN\User med dina egna värden.

Kontrollera IPC$ och 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 *

Efter varje kommando anger du lösenordet vid den dolda prompten. The command completed successfully bekräftar autentiseringsuppgifterna och respektive SMB-åtkomst för detta test. Framgång med ADMIN$ visar också att kontot har administrativ delningsåtkomst.

Kontrollera fjärrregistret

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

En utdataregisterrad för ProgramFilesDir bekräftar att Remote Registry kan nås via den befintliga sessionen. För The network path was not found kontrollera först tjänsten, SMB-sökvägen och brandväggen; på Access is denied Kontrollera kontorättigheter, UAC-fjärrtoken och den identitet som faktiskt används.

Kontrollera WMI

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

Ange lösenordet endast vid kommandotolken. Ett operativsystemnamn under Name bekräftar WMI-åtkomst för detta test. Om wmic inte är tillgängligt i den version av Windows du använder, använd inte ett oprövat ersättningskommando. Kontrollera istället WMI-brandväggsreglerna och värdförberedelserna och utför den faktiska valideringen via nästa Managed Risk-skanning.

Städa alltid sessioner

Efter testet, ta bort båda anslutningarna, även om ett mellansteg misslyckades:

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

Använd sedan net use för att kontrollera att det inte längre finns någon anslutning till det listade testmålet och stäng administratörsterminalen.

Validera resultatet i nästa skanning

Efter nästa planerade körning kontrollerar du under Managed Risk > Report History om den interna sårbarhetsrapporten har skapats. Autentiserade resultat är vanligtvis mer detaljerade än oautentiserade. Ett visst antal fynd är dock inte ett framgångskriterium: operativsystem, öppna portar, installerad programvara, plugins som används och skanningstyp påverkar resultatet.

För ett tillförlitligt test:

Bekräfta att Scan type: Authenticated och de avsedda autentiseringsuppgifterna är valda i skanningen.
Se till att målsystemen är inom skanningsomfånget och kan nås av skanningsapparaten.
För Windows, kontrollera först de fyra områdena IPC$, ADMIN$, Remote Registry och WMI.
För Linux och macOS kontrollera SSH-tillgänglighet, nyckel eller Kerberos-konfiguration och den avsedda behörighetshöjningen.
Kontrollera värd- och mellanbrandväggar för blockerad trafik från skanningsenhetens IP-adress.
Ändra först därefter fälten för autentiseringsuppgifter och validera dem igen vid nästa skanning.

Om resultaten fortfarande verkar vara en oautentiserad skanning eller förblir oväntat ofullständiga, skicka en begäran till Managed Risk-teamet på Threat Analysis Center > Cases > Create case > Managed Risk service request. Ange skanningsnamn, tidsfönster med tidszon, skannernamn, måltyp, autentiseringstyp, påverkade anonymiserade mål, observerat resultat och kontroller som redan utförts. Bifoga inte lösenord, hash, privata nycklar eller fullständig känslig konsolutgång.

Redigera eller ta bort autentiseringsuppgifter

För att redigera under Managed Risk > Settings > Credentials i kolumnen Actions öppnar du trepunktsmenyn, väljer Edit, justerar fälten och sparar med Update. Validera ändringen vid nästa schemalagda skanning.

Innan du tar bort, kontrollera först alla skanningskonfigurationer som använder autentiseringsuppgifterna. Välj sedan Delete i samma trepunktsmeny och radera den permanent i dialogen med Confirm. Radering tar bort autentiseringsuppgifterna från alla skanningskonfigurationer där den användes och kan påverka deras framtida autentiserade körningar. Öppna sedan varje påverkad skanning, kontrollera det återstående valet av autentiseringsuppgifter och, om nödvändigt, tilldela förberedda ersättningsuppgifter.

Listan med autentiseringsuppgifter kan läsas in på nytt med uppdateringssymbolen uppe till höger. Symbolen bekräftar att listvyn har uppdaterats, men inte att autentiseringsuppgifterna fungerar på ett mål. Det kan endast testet eller nästa skanning visa.