Sophos Managed Risk: konfigurowanie poświadczeń do skanów uwierzytelnionych

Podczas uwierzytelnionego wewnętrznego skanowania luk skaner loguje się do systemu docelowego. Dzięki temu może sprawdzić lokalne pliki, wpisy rejestru, zainstalowane oprogramowanie i konfiguracje niewidoczne podczas skanowania bez poświadczeń. Zwykle wykrywa więc więcej luk. Skan nieuwierzytelniony nadal jest jednak przydatny, ponieważ lepiej odzwierciedla to, do czego mógłby uzyskać dostęp zewnętrzny atakujący bez konta.

Bezpieczna procedura podzielona jest na cztery etapy:

Przygotuj dedykowane konto skanowania z uprawnieniami niezbędnymi do planowanych kontroli.
Udostępnij docelowy system operacyjny dla SMB/WMI lub SSH.
Utwórz odpowiedni typ poświadczeń w obszarze Managed Risk > Settings > Credentials > Add credential.
Przypisz poświadczenia do wewnętrznego skanu luk z ustawieniem Scan type: Authenticated i zweryfikuj wynik podczas następnego skanowania.

Przygotuj systemy docelowe przed Sophos Fusion

Przygotowanie odbywa się bezpośrednio w docelowym systemie Windows, macOS lub Linux i jest niezależne od późniejszego wprowadzania poświadczeń w Sophos Fusion. Nawet poprawnie wypełniony formularz Fusion nie zastąpi brakujących udziałów, usług ani uprawnień w systemie docelowym.

Windows

W przypadku urządzeń i serwerów Windows innych niż kontrolery domeny użyj dedykowanego konta lokalnego należącego do lokalnej grupy Administratorzy. Kontrolery domeny wymagają natomiast administratora domeny i powinny należeć do oddzielnego skanu z własnymi poświadczeniami. Dzięki temu konto o szerszych uprawnieniach nie jest używane na serwerach członkowskich ani klientach.

Sprawdź przed przypisaniem:

Zasady bezpieczeństwa, takie jak Deny access to this computer from the network i Access this computer from the network, inne zasady lokalne, ochrona punktów końcowych oraz IPS/IDS nie mogą blokować planowanych kontroli z użyciem poświadczeń.
Niektóre kontrole lokalne wymagają programu PowerShell 5.0 lub nowszego.
Skaner wymaga dostępu przez SMB i WMI. Zapora hosta musi zezwalać na połączenia z adresu IP urządzenia skanującego Managed Risk; w przypadku File and Printer Sharing istotne są porty TCP 139 i 445. Skaner musi mieć również dostęp do portów pozostałych sprawdzanych usług.
Udziały administracyjne IPC$, ADMIN$ i C$ muszą być dostępne.
Remote Registry musi być uruchomiony lub można go uruchomić z uprawnieniami administratora używanymi do skanowania.
W udokumentowanych scenariuszach kont Windows ustawienie Network access: Sharing and security model for local accounts musi mieć wartość Classic - local users authenticate as themselves. Dotyczy to zarówno konta domenowego używanego do kontroli lokalnych, jak i konta lokalnego; logowanie jako gość nie wystarcza do przeprowadzenia lokalnych kontroli bezpieczeństwa.
W przypadku kont lokalnych UAC nie może filtrować tokena zdalnego administratora. Udokumentowane warianty to wyłączenie UAC lub wartości DWORD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy o wartości 1. Wdrażaj taką zmianę zabezpieczeń dopiero po wewnętrznym procesie zmian i ograniczaj się do systemów, których to dotyczy.
Dla WMI włącz predefiniowane reguły ruchu przychodzącego Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) i Windows Management Instrumentation (DCOM-In). Jeśli to możliwe, ogranicz reguły do adresu IP urządzenia skanującego.

Nie zastępuj tych wymagań ogólną regułą zapory zezwalającą na ruch z dowolnego źródła. Jeśli urządzenie skanujące i system docelowy znajdują się w różnych sieciach VLAN, specyfikacja skanu wymaga pełnego dwukierunkowego dostępu urządzenia do wszystkich portów i protokołów w docelowej sieci VLAN. Routing i zapory pośrednie muszą zezwalać na ten dostęp; ogranicz reguły do urządzenia i planowanych zakresów docelowych.

macOS

Cele macOS są sprawdzane za pomocą SSH: albo za pomocą pary kluczy, albo za pomocą poświadczeń użytkownika i sudo lub su. W przypadku pełnego skanowania lokalnego konto skanowania musi należeć do grupy Administratorzy i mieć Full Disk Access. Przy mniejszej liczbie uprawnień możliwe są indywidualne kontrole, takie jak określenie poziomu poprawki, ale nie ten sam poziom sprawdzania. Dedykowane konto musi mieć taką samą nazwę użytkownika we wszystkich planowanych systemach macOS; jeśli to możliwe, wybierz dostęp za pomocą klucza zamiast poświadczeń użytkownika.

Przed skanowaniem obowiązują następujące wymagania:

Włącz Remote Login i zezwól na dedykowane konto skanowania.
W ustawieniu systemowym Remote Login włącz opcję Allow full disk access for remote users. Ponadto w obszarze Privacy & Security przyznaj Full Disk Access obu udokumentowanym procesom: /usr/libexec/sshd-keygen-wrapper i /Library/NessusAgent/run/sbin/nessus-service.
W przypadku Kerberos, sshd musi obsługiwać Kerberos, używać metody interakcji gssapi-with-mic, a odwrotny DNS musi działać poprawnie.
Serwer SSH i skaner muszą mieć wspólny obsługiwany szyfr. blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc i AES-CTR są udokumentowane. Generalnie nie aktywuj przestarzałego szyfrowania tylko na potrzeby skanowania; najpierw sprawdź już bezpieczną opcję wspólną.
W przypadku dostępu opartego na kluczu umieść klucz publiczny w pliku authorized_keys dedykowanego konta, a klucz prywatny udostępnij skanerowi wyłącznie w bezpiecznej postaci.

Linux

Systemy Linux są również sprawdzane przez SSH — za pomocą pary kluczy albo poświadczeń użytkownika i sudo lub su. Aby uzyskać największą możliwą dokładność kontroli, konto musi umożliwiać wykonywanie poleceń z uprawnieniami roota. Konto o mniejszych uprawnieniach może dostarczyć częściowe wyniki, ale nie obejmie w pełni kontroli konfiguracji i plików.

Sprawdź przed skanowaniem:

Utwórz dedykowanego użytkownika SSH o dokładnie tej samej nazwie we wszystkich planowanych systemach docelowych. W przypadku uwierzytelniania wyłącznie kluczem konto nie może mieć prawidłowego hasła; klucz publiczny umieść w authorized_keys, a klucz prywatny przechowuj bezpiecznie na skanerze.
Włącz połączenie SSH i zamierzone podniesienie uprawnień z sieci urządzenia skanującego.
W przypadku Kerberos, sshd musi obsługiwać Kerberos, używać gssapi-with-mic i mieć poprawnie działający odwrotny DNS.
Konfiguracja powłoki konta skanowania wymaga zmiennej PS1 zawierającej co najmniej cztery znaki. Bardzo krótki monit, taki jak PS1='$ ', może znacznie spowolnić skanowanie.
Te same udokumentowane opcje dotyczą szyfru SSH, co w przypadku macOS. Korzystaj z istniejących, bezpiecznych, wspólnych algorytmów i nie rozszerzaj niepotrzebnie konfiguracji hosta.

Ogólne przygotowanie hosta SSH może obsługiwać bardziej nowoczesne typy kluczy. Jednak w Managed Risk > Settings > Credentials, Public Key obecnie akceptuje tylko klucze RSA i DSA w formacie OpenSSH. Dlatego też typ klucza, który nie jest tam obsługiwany, nie może zostać użyty poprzez zmianę systemu docelowego.

Utwórz dane uwierzytelniające w Sophos Fusion

W obszarze Managed Risk > Settings otwórz zakładkę Credentials i wybierz Add credential. W Create credential najpierw wybierz typ. Uwierzytelnianie Plaintext nie jest obsługiwane.

SNMPv3

SNMPv3 przeznaczony jest dla urządzeń sieciowych z SNMP w wersji 3. Wypełnij następujące pola:

Credential type: SNMPv3.
Credential name: unikalna nazwa, na przykład snmpv3-core-switches.
Description: opcjonalna uwaga dotycząca docelowego obszaru urządzenia.
Username: użytkownik konta SNMPv3.
Port: standardowy 161; zmienić tylko wtedy, gdy obiekt docelowy udostępnia SNMPv3 na innym porcie.
Security Level: Authentication and privacy. Ta kombinacja uwierzytelniania i szyfrowania jest obecnie jedyną opcją.
Authentication algorithm: SHA-256, SHA-384 lub SHA-512 pasujące do konfiguracji docelowej.
Authentication password: hasło uwierzytelniające konta SNMPv3.
Privacy algorithm: AES-256 lub AES-256C pasujące do konfiguracji docelowej.
Privacy password: hasło prywatności konta SNMPv3.
Zapisz za pomocą Create.

Windows

W przypadku Credential type: Windows wprowadź najpierw unikalny Credential name i opcjonalnie Description. Następnie wybierz jeden z trzech wariantów pod Authentication method:

Kerberos: wprowadź Username, Password, Domain, Key Distribution Center (KDC), KDC Port (domyślnie 88), KDC Transport (TCP lub UDP) oraz Realm.
NTLM Hash: wprowadź Username, Hash i Domain. Traktuj skrót NTLM jak hasło i nigdy nie umieszczaj go w materiałach diagnostycznych.
Password: wprowadź Username, Password oraz opcjonalnie Domain, jeśli jest wymagane.

Zapisz za pomocą Create. W przypadku kont lokalnych użytkownik musi odpowiadać danemu systemowi docelowemu; w skanach kontrolerów domeny użyj poświadczeń administratora domeny zarezerwowanych do tego celu.

SSH dla Linux i macOS

Dla Credential type: SSH wybierz unikalny Credential name, opcjonalnie Description, a następnie Authentication method:

Kerberos: wprowadź Username, Key Distribution Center (KDC), KDC Port (domyślnie 88), KDC Transport (TCP lub UDP) oraz Realm.
Password: wprowadź Username i Password. Wybierz Elevate privileges with tylko wtedy, gdy wymaga tego przygotowana konfiguracja systemu docelowego.
Public Key: wprowadź Username. W sekcji Private key użyj opcji Add File, aby przesłać plik klucza prywatnego, lub wklej klucz bezpośrednio. Obsługiwane są tylko klucze RSA i DSA w formacie OpenSSH. W przypadku chronionego klucza wprowadź również Private key passphrase.

W przypadku Public Key wybierz pomiędzy Nothing i sudo w obszarze Elevate privileges with. W przypadku sudo wpisz także sudo user i, jeśli to konieczne, sudo password. Konto i wybrana metoda podniesienia uprawnień muszą odpowiadać przygotowanej konfiguracji systemu docelowego.

Opcjonalnie w Targets można wprowadzić nazwy hostów, adresy IP lub bloki CIDR, aby nadać priorytet poświadczeniom klucza publicznego dla tych celów. Oddziel wiele wartości przecinkami lub spacjami. To ustawienie priorytetów nie zastępuje definicji celu skanowania ani wyboru danych uwierzytelniających podczas skanowania.

Zapisz za pomocą Create.

VMware ESX SOAP API

Ten typ jest przeznaczony dla hostów VMware ESX/ESXi:

Credential type: VMware ESX SOAP API.
Credential name: unikalna nazwa.
Description: opcjonalna uwaga dotycząca zamierzonych hostów.
ESX SOAP API Authentication Method: Username and Password. Jest to obecnie jedyna opcja.
Username: konto VMware z dostępem administracyjnym do hosta ESX/ESXi.
Password: Hasło do tego konta.
Zapisz za pomocą Create.

W przypadku kompleksowych audytów to konto wymaga dostępu administracyjnego do hosta. Poświadczenia są przeznaczone dla środowisk wirtualizacji VMware, a nie dla obiektów docelowych Windows lub SSH w maszynach wirtualnych.

Przypisz dane uwierzytelniające do uwierzytelnionego skanowania

Zapisane poświadczenia nie uruchamiają skanu. Utwórz wewnętrzne skanowanie w poszukiwaniu luk w My Products > Managed Risk > Scans > Internal i skonfiguruj je na stronie Create Vulnerability Scan w następujący sposób:

Wybierz podłączone urządzenie skanujące pod Select scanner.
Wprowadź nazwę i opis w polu Configure scan details.
Ustaw Scan type na Authenticated.
Wybierz odpowiednie poświadczenia w obszarze Select credentials. Podczas jednego skanowania możliwych jest maksymalnie dziesięć poświadczeń.
Wpisz zamierzone adresy IP, zakresy CIDR lub nazwy hostów w Add scan targets i zastosuj je w Add. Potwierdź indywidualnie zapisane wartości za pomocą Enter; Wstawione listy należy oddzielić przecinkami.
Ustaw dzień, godzinę i strefę czasową w Schedule the weekly scan i zapisz je w prawym górnym rogu za pomocą Save.

Rozdziel poświadczenia według systemu operacyjnego, strefy zaufania i wymagań dotyczących ochrony. W szczególności poświadczenia administratora domeny nie należą do szerokiego zakresu zwykłych klientów Windows. Jeśli wymaganych jest więcej niż dziesięć poświadczeń, podziel obszar docelowy na zrozumiałe skany, zamiast łączyć poświadczenia lub rozszerzać uprawnienia.

Przetestuj poświadczenia systemu Windows przed następnym skanowaniem

Opisane testy poświadczeń dotyczą obecnie wyłącznie systemu Windows. Należy je uruchomić z systemu Windows w tej samej podsieci co urządzenie skanujące i użyć dokładnie tych samych poświadczeń. Pozwala to możliwie wiernie odtworzyć warunki sieciowe skanera.

Otwórz Command Prompt lub PowerShell jako administrator. W tym przykładzie 192.0.2.25 jest adresem dokumentacji i należy go zastąpić wewnętrznym adresem IP systemu docelowego. LAB-SRV-025\svc_mrisk to przykładowe konto lokalne; w przypadku konta domenowego użyj formatu DOMAIN\User z własnymi wartościami.

Sprawdź IPC$ i 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 *

Po każdym poleceniu wprowadź hasło w ukrytym wierszu polecenia. The command completed successfully potwierdza poświadczenia i odpowiedni dostęp SMB dla tego testu. Sukces ADMIN$ pokazuje również, że konto ma dostęp administracyjny do udostępniania.

Sprawdź rejestr zdalny

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

Wyjściowy wiersz rejestru dla ProgramFilesDir potwierdza, że Rejestr zdalny jest dostępny poprzez istniejącą sesję. W przypadku The network path was not found najpierw sprawdź usługę, ścieżkę SMB i zaporę sieciową; w przypadku Access is denied sprawdź uprawnienia konta, zdalny token UAC i faktycznie używaną tożsamość.

Sprawdź WMI

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

Wprowadź hasło tylko w wierszu poleceń. Nazwa systemu operacyjnego pod Name potwierdza dostęp do WMI dla tego testu. Jeśli wmic nie jest dostępne w używanej wersji systemu Windows, nie używaj nieprzetestowanego polecenia zamiany. Zamiast tego sprawdź reguły zapory WMI i przygotowanie hosta, a następnie przeprowadź rzeczywistą weryfikację podczas następnego skanu Managed Risk.

Zawsze sprzątaj sesje

Po przetestowaniu usuń oba połączenia, nawet jeśli etap pośredni nie powiódł się:

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

Następnie użyj net use, aby sprawdzić, czy na liście nie ma już żadnego połączenia z celem testu, i zamknij terminal administracyjny.

Zweryfikuj wynik podczas następnego skanowania

Po kolejnym zaplanowanym uruchomieniu pod Managed Risk > Report History sprawdź, czy został utworzony wewnętrzny raport o podatnościach. Uwierzytelnione wyniki są zazwyczaj bardziej szczegółowe niż te nieuwierzytelnione. Jednak określona liczba wyników nie jest kryterium sukcesu: na wynik mają wpływ system operacyjny, otwarte porty, zainstalowane oprogramowanie, użyte wtyczki i typ skanowania.

Aby uzyskać wiarygodny test:

Upewnij się, że podczas skanowania wybrano Scan type: Authenticated i zamierzone poświadczenia.
Upewnij się, że systemy docelowe znajdują się w obszarze skanowania i że urządzenie skanujące może do nich dotrzeć.
W przypadku Windows najpierw sprawdź cztery obszary IPC$, ADMIN$, Remote Registry i WMI.
W przypadku Linux i macOS sprawdź dostępność SSH, konfigurację klucza lub protokołu Kerberos oraz planowane podniesienie uprawnień.
Sprawdź zapory hosta i pośrednie pod kątem zablokowanego ruchu z adresu IP urządzenia skanującego.
Dopiero wtedy zmień pola poświadczeń i zweryfikuj je ponownie podczas następnego skanowania.

Jeśli wyniki nadal wyglądają na nieuwierzytelnione skanowanie lub są nieoczekiwanie niekompletne, prześlij prośbę do zespołu Managed Risk pod adresem Threat Analysis Center > Cases > Create case > Managed Risk service request. Określ nazwę skanowania, okno czasowe ze strefą czasową, nazwę skanera, typ celu, typ danych uwierzytelniających, anonimowe cele, których to dotyczy, zaobserwowany wynik i już przeprowadzone kontrole. Nie dołączaj haseł, skrótów, kluczy prywatnych ani pełnych poufnych danych wyjściowych konsoli.

Edytuj lub usuń poświadczenia

Aby edytować pod Managed Risk > Settings > Credentials, otwórz menu z trzema kropkami w kolumnie Actions, wybierz Edit, dostosuj pola i zapisz za pomocą Update. Zatwierdź zmianę podczas następnego zaplanowanego skanowania.

Przed usunięciem najpierw sprawdź wszystkie konfiguracje skanowania korzystające z poświadczeń. Następnie w tym samym trzypunktowym menu wybierz Delete i usuń go trwale w oknie dialogowym z Confirm. Usunięcie spowoduje usunięcie poświadczeń ze wszystkich konfiguracji skanowania, w których zostało użyte, i może mieć wpływ na ich przyszłe uwierzytelnione przebiegi. Następnie otwórz każdy skan, którego dotyczy problem, sprawdź pozostały wybór poświadczeń i, jeśli to konieczne, przypisz przygotowane poświadczenie zastępcze.

Listę danych uwierzytelniających można załadować ponownie, korzystając z symbolu odświeżania w prawym górnym rogu. Potwierdza, że widok listy został zaktualizowany, ale nie potwierdza, że dane uwierzytelniające działają na obiekcie docelowym; Dopiero test lub następny skan dostarcza tego dowodu.