Obecnie największym problemem osób
odpowiedzialnych za bezpieczeństwo w dużych organizacjach jest ochrona kont
uprzywilejowanych. W środowisku opartym o usługi Active Directory typowy scenariusz
ataku po uzyskaniu dostępu do sieci wewnętrznej polega na identyfikacji i
kradzieży danych uwierzytelniających kont posiadających najwyższe uprawnienia –
czyli administratorów.
Poniższy przykład pokazuje dość liczną grupę administratorów
domeny (prawa strona grafu wygenerowanego przez narzędzie BloodHound [1]).
Intruz łatwo może zidentyfikować uprzywilejowane konta a następnie znaleźć
najszybszą ścieżkę dostępu do tych kont [1,2,3].
Ograniczenie możliwości atakującego (przeprowadzenie ataków
takich jak Pass-the-Hash czy Pass-the-Ticket) wymaga wielu działań. Czym
większa organizacja, tym oczywiście trudniejsze jest wdrożenie zmian ale też
przyzwyczajeń administratorów. Poniżej opiszemy fragmenty koncepcji
rekomendowanej przez firmę Microsoft – Enhanced Security Administrative Environment (ESAE) Administrative
Forest.
W dużym uproszeniu podejście to polega na utworzeniu lasu
administracyjnego, który będzie miał szereg zabezpieczeń uniemożliwiających
(lub w znacznym stopniu utrudniający) skuteczny atak konta administratorów
domeny. W kolejnych krokach można zwiększać zakres funkcjonalności
realizowanych w lesie produkcyjnym z poziomu lasu administracyjnego.
W poniższym przykładzie skupimy się na ochronie kont w
grupie domain admins dla lasu produkcyjnego. Co ciekawe według zaleceń
producenta [4] w tej grupie nie powinno być żadnych kont wykorzystywanych w
codziennych pracach administracyjnych (w praktyce jest zazwyczaj inaczej):
„As is the case with the Enterprise Admins (EA) group,
membership in the Domain Admins (DA) group should be required only in build or
disaster recovery scenarios. There should be no day-to-day user accounts in the
DA group with the exception of the built-in Administrator account for the
domain”.
Stosując się do zaleceń powinniśmy usunąć z tej grupy uprzywilejowanej
wszystkie konta (powinno pozostać jedno konto awaryjne – konto build-in\Administrator).
W artykule opiszemy kroki niezbędne do utworzenie
oddzielnego lasu administracyjnego, czyli jednego z elementów chroniących konta
uprzywilejowane. Wykorzystując funkcję Shadow Principle będziemy na określony
czas (tzw. Just in Time Administration) dodawali użytkownika (zwykłe konto w
domenie administracyjnej) do grupy Domain Admins w domenie produkcyjnej.
Zanim jednak zaczniemy, należy pamiętać, że równie istotne
są też inne działania opisane poniżej. Wszystkie one mają jeden nadrzędy cel –
ograniczenie lub uniemożliwienie pozyskania danych uwierzytelniających kont
uprzywilejowanych. Dla przykładu, jeśli zablokujemy możliwość logowania się
kontem uprzywilejowanym na wszystkie stacje robocze i serwery w organizacji z
wyjątkiem kontrolerów domen, intruz przejmując kontrolę na serwerem czy stacją
roboczą nie będzie mógł pozyskać danych uwierzytelniających.
Inne działania związane z ograniczeniem ataków nakierowanych
na kradzież danych uwierzytelniających w Active Directory to:
- Ograniczenie ilości obiektów w grupach uprzywilejowanych. Grupy uprzywilejowane to:
- Enterprise Admins
- Domain Admins
- Schema Admins
- BUILDIN\Administrators
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Domain Controllers
- Read-only Domain Controllers
- Group Policy Creators Owners
- Cryptographic Operators
- Distributed COM Users
- Inne grupy którym delegowano uprawnienia do zarządzania usługą AD lub zarządzania danymi w usłudze AD.
- Utworzenie oddzielnych kont, które są używane wyłącznie do zarządzania kontrolerami domeny.
- Ważne jest, aby na te konta (służące do zarządzania kontrolerami domeny) logować się z oddzielnych - dedykowanych komputerów – tzw. PAW (ang. Privileged Access Workstations). Jeśli administrator domeny używa tego samego komputera aby logować się na konto zwykłego użytkownika (konto do poczty czy przeglądania stron www) i konto administratora domeny nasze działania mogą być mało skutecznie. Intruz przejmując stację roboczą może zainstalować keylogger i uzyskać dane do konta administracyjnego (np. podczas nawiązywania przez administratora sesji RDP).
- Wprowadzenie restrykcji dotyczących na jakie komputery można się logować za pomocą kont służących do zarządzania kontrolerami domen (ale też innych kont uprzywilejowanych). Tutaj należy zacząć od podziału lasu produkcyjnego na poziomy zaufania (ang. Tiers). Zalecane jest utworzenie trzech poziomów Tier 0 – bardzo ograniczona grupa obiektów (kont, komputerów, serwerów) służąca do zarządzania AD (po analizie może się okazać że ta grupa nie jest taka mała, gdyż może zawierać na przykład agentów działających na kontach serwisowych jak program AV), Tier 1 – wszelkie serwery produkcyjne oraz Tier 2 – sieć użytkowników (czyli między innymi stacje robocze) z reguły najmniej zaufana.
- Implementacja dwuskładnikowego uwierzytelniania. Przy okazji należy pamiętać o regularnym resecie wartości NTLM hash gdy będziemy korzystali z kart inteligentnych.
- Utwardzenie (ang. hardening) kontrolerów domeny w lesie produkcyjnym oraz lesie administracyjnym. W zakresie tego punktu są między innymi:
- Bezpieczeństwo fizyczne (włączając w to między innymi dedykowane szafy na serwery fizyczne czy wirtualne, kontrola dostępu do interfejsów zarządzających, szyfrowanie dysków, bezpieczny start systemu z UEFI)
- Konfiguracja ustawień bezpieczeństwa - Dobrym przykładem są polityki znajdujące się w Microsoft Security Compliance Toolkit. Dodatkowo należy skonfigurować firewall WFAS i ograniczyć możliwość uruchamiania niektórych plików wykonywalnych.
- Uaktualnianie środowiska. Najlepiej zainstalować i skonfigurować dedykowany serwer uaktualnień WSUS. Poprawki powinny być instalowane automatycznie w domenie administracyjnej.
- Wydzielenie odseparowanej podsieci. Hosty wchodzące w skład lasu administracyjnego powinny być chronione systemem firewall a ruch pomiędzy lasami powinien być monitorowany. Byłoby dobrze gdyby monitorowanie pozwalało na szczegółową analizę protokołów związanych ze środowiskiem Microsoft - takich jak Server Message Block (SMB).
Są to zalecenia, które docelowo należy stosować w obydwu
lasach a część z nich dotyczy wszystkich kont uprzywilejowanych.
Założenia wstępne dotyczące konfiguracji lasu administracyjnego:
- Las produkcyjny ma poziom funkcjonalny domeny i lasu Windows 2012 R2. Jest to obecnie często spotykana konfiguracja.
- Zakładamy, że będzie jedno dedykowane konto do zarządzania domeną produkcyjną. Konto zostanie utworzenie w lesie administracyjnym. Musi to być standardowe konto bez żadnych dodatkowych uprawnień.
- Przyjęliśmy że las produkcyjny to ad.prevenity.com. Natomiast las administracyjny to bastion.prevenity.com.
- Las administracyjny, który będziemy konfigurowany jest oparty o Windows 2016 (tutaj poziom funkcjonalny lasu to Windows2016Forest). Służy on do zarządzania kontami, grupami i komputerami administratorów domeny. Do tego lasu muszą być podłączone stacje robocze PAW.
- Kontrolery domen z systemem Windows 2012 R2 muszą posiadać poprawkę KB3172614 [5].
Krok 1: Utworzenie
lasu administracyjnego
Pominiemy opis instalacji i konfiguracji serwera Windows
Server 2016. Poniżej znajduje się lista głównych zadań które należy wykonać w
celu zarządzania grupą domain admins. Należy pamiętać, że będzie to odizolowane
środowisko i dostęp do niego powinien być zabezpieczony. Ponieważ w tym
środowisku będzie bardzo mała ilość komputerów i użytkowników można
skonfigurować mechanizmy bezpieczeństwa, które w środowisku produkcyjnym byłyby
trudnie do wdrożenia (na przykład całkowite wyłączenie obsługi NTLM).
Istotne jest aby Windows Server 2016 działa w trybie funkcjonalności lasu Windows
Server 2016. Musi też tyć włączona funkcja AD Privileged Access Management.
Poniżej komendy uruchamiane, które instalują i konfigurują
komponenty nowego lasu i usług katalogowych.
$domainName = 'bastion.prevenity.com'
$pwd = ‘_haslo_'
$securepwd = convertto-securestring $pwd -asplaintext -force
Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName $domainName -InstallDns -Force -Confirm:$false -SafeModeAdministratorPassword $securepwd
$pwd = ‘_haslo_'
$securepwd = convertto-securestring $pwd -asplaintext -force
Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName $domainName -InstallDns -Force -Confirm:$false -SafeModeAdministratorPassword $securepwd
Krok 2: Privileged Access Management
W kolejnym kroku na kontrolerze domeny z Windows 2016
włączamy funkcje Privileged Access Management (PAM).
Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfiguratioSet -Target bastion.prevenity.com
Krok 3: Konfiguracja
zaufania
Następnie tworzymy jednokierunkowe zaufanie pomiędzy lasami
(ad.prevenity.com a (->) bastion.prevenity.com). Należy pamiętać o poprawnej
konfiguracji DNS gdyż serwery muszą rozwiązywać nazwy występujące w obu lasach.
Tworząc jednokierunkowe zaufanie włączamy SIDHistory –
funkcję które nie zablokuje identyfikatorów SID dla grup Domain Admins.
Umożliwi to zalogowanie się użytkownika z domeny Bastion do serwera w domenie
produkcyjnej z wysokimi uprawnieniami.
- Komendy uruchamiane na kontrolerze domeny w lesie produkcyjnym
.prevenity.com /PasswordD:* /UserO:administrator@ad.prevenity.com /PasswordO:*
netdom trust ad.prevenity.com /Domain:bastion.prevenity.com /ForestTRANsitive:Yes
netdom trust ad.prevenity.com /Domain:bastion.prevenity.com /EnableSIDHistory:Yes
netdom trust ad.prevenity.com /Domain:bastion.prevenity.com /EnablePIMTrust:Yes
netdom trust ad.prevenity.com /Domain:bastion.prevenity.com /Quarantine:No
- Komenda uruchamiana na kontrolerze domeny w lesie administracyjnym
netdom trust bastion.prevenity.com /domain:ad.prevenity.com /ForestTRANsitive:Yes
4. Konfiguracja Kerberos AES encryption
Ponieważ konfigurujemy zaufanie z serwerem Windows 2012 R2 z
poziomem funkcjonalności lasu Windows2012R2 włączamy wsparcie szyfrowania AES
dla protokołu Kerberos. Na kontrolerze domeny w lesie administracyjnym
uruchamiamy Active Directory Users and Computers (dsa.msc). Następnie włączamy
Advanced Features. W kontenerze System wybieramy obiekt ad.prevenity.com i we
właściwościach zaznaczamy „The other domain supports Kerberos AES Encryption”.
5. Utworzenie Shadow
Principal
W kolejnym kroku na kontrolerze domeny w lesie
administracyjnym za pomocą funkcji Shadow Prinicipal tworzymy kopię grupy
uprzywilejowanej Domain Admins z lasu produkcyjnego. W lesie administracyjnym kontener
Shadow Principal będzie miał przedrostek PROD-.
Komenda uruchamiana na kontrolerze w lesie administracyjnym:
$ProdPrincipal = 'Domain Admins'
$ProdDC = 'dc.ad.prevenity.com'
$ShadowSuffix = 'PROD-'
$ProdShadowPrincipal = Get-ADGroup -Identity $ProdPrincipal -Properties ObjectSID -Server $ProdDC
$ShadowPrincipalContainer = 'CN=Shadow Principal Configuration,CN=Services,'+(Get-ADRootDSE).
configurationNamingContext
New-ADObject -Type msDS-ShadowPrincipal -Name "$ShadowSuffix$($ProdShadowPrincipal.SamAccount
Name)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ProdShadowPrincipal.ObjectSID}
$ProdDC = 'dc.ad.prevenity.com'
$ShadowSuffix = 'PROD-'
$ProdShadowPrincipal = Get-ADGroup -Identity $ProdPrincipal -Properties ObjectSID -Server $ProdDC
$ShadowPrincipalContainer = 'CN=Shadow Principal Configuration,CN=Services,'+(Get-ADRootDSE).
configurationNamingContext
New-ADObject -Type msDS-ShadowPrincipal -Name "$ShadowSuffix$($ProdShadowPrincipal.SamAccount
Name)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ProdShadowPrincipal.ObjectSID}
W tym momencie za pomocą narzędzia ADSI Edit możemy
wyświetlić zawartość kontenera Shadow Principal. Wartości SID z lasu
produkcyjnego odpowiada wartości msDS-ShadowPrincipal w lesie administracyjnym.
Był to ostatni krok wymagany do konfiguracji mechanizmu just
in time administration. Podczas codziennej pracy administrator chcący uzyskać
dostęp do kontrolera domeny w lesie produkcyjnym musi wykonać komendę, która
doda do grupy Domain Admins na określony czas konto użytkownika z domeny w
lesie administracyjnym.
W lesie administracyjnym zakładamy konto zwykłego
użytkownika – jarek.adm2, pamiętając o innych (opisanych powyżej) ustawieniach
bezpieczeństwa dla tego konta jak na przykład logowanie wyłącznie z dedykowanej
stacji roboczej (PAW).
Za pomocą poniższej komendy dodamy do Prod-Domain-Admins
konto jarek.adm2 na okres 10 minut. Wartość TTL określa czas na jaki konto
będzie członkiem grupy.
Set-ADObject -Identity "CN=Prod-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=bastion,DC=prevenity,dc=com" -Add @{'member'="<TTL=600,CN=jarek.adm2,OU=PROD-Shadow,DC=bastion,DC=prevenity,DC=com>"}
Po wykonaniu tego polecenia możliwe jest zalogowanie się na
konto z domeny administracyjnej bastion do kontrolera w lesie produkcyjnym.
W celu umożliwienia użytkownikom z lasu administracyjnego dostępu
do Group Policy Objects wymagana jest zamiana uprawnień do każdego GPO w
domenie produkcyjnej (zmodyfikowanie atrybutu DefaultSecurityDecriptor).
Źródła:
[6] https://blogs.technet.microsoft.com/389thoughts/2017/06/19/ad-2016-pam-trust-how-it-works-and-safety-advisory/
[7] https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access
[8] https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/environment-overview
[7] https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access
[8] https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/environment-overview
[9] Wszystkie komendy znajdują się na https://github.com/Prevenity/AD-Hardening
