Włączanie komunikacji zdalnej z wieloma przeskokami w programie Windows PowerShell
Innym wyzwaniem związanym z komunikacji zdalnej jest delegowanie poświadczeń między wieloma połączeniami zdalnymi. Domyślnie poświadczenia mogą być delegowane tylko przez jedno połączenie lub przeskok. To delegowanie ograniczeń uniemożliwia dalsze delegowanie poświadczeń przez komputer zdalny, ponieważ może to spowodować dodatkowe zagrożenie bezpieczeństwa.
Ogólnie rzecz biorąc, jest to scenariusz, który chcemy rozwiązać:
- Jesteś zalogowany do ServerA.
- Z poziomu serweraA uruchom zdalną sesję programu PowerShell w celu nawiązania połączenia z serweremB.
- Polecenie uruchamiane w usłudze ServerB za pośrednictwem sesji komunikacji zdalnej programu PowerShell próbuje uzyskać dostęp do zasobu na serwerze ServerC.
- Odmowa dostępu do zasobu na serwerze ServerC, ponieważ poświadczenia użyte do utworzenia sesji komunikacji zdalnej programu PowerShell nie są przekazywane z serweraB do serweraC.
Potrzeba wykonania delegacji z wieloma przeskokami (czyli tzw. multi-hop) może często występować w środowiskach produkcyjnych. Na przykład w niektórych organizacjach administratorzy nie mogą łączyć się bezpośrednio z komputerów klienckich z serwerem w centrum danych. Zamiast tego muszą nawiązać połączenie z bramą pośrednią lub serwerem przesiadkowym, a następnie nawiązać połączenie z serwerem, który zamierza zarządzać. W domyślnej konfiguracji komunikacja zdalna nie zezwala na takie podejście. Po nawiązaniu połączenia z komputerem zdalnym poświadczenie może przejść nie dalej niż komputer zdalny. Próba uzyskania dostępu do dowolnego zasobu, który nie znajduje się na tym komputerze, zwykle powoduje niepowodzenie, ponieważ dostęp nie jest dołączony do poświadczeń. Rozwiązaniem jest włączenie dostawcy obsługi zabezpieczeń poświadczeń (CredSSP).
Włączanie protokołu CredSSP
CredSSP buforuje poświadczenia na serwerze zdalnym (ServerB, z poprzedniego przykładu). W związku z tym należy pamiętać, że użycie protokołu CredSSP otwiera potencjalne ataki kradzieży poświadczeń. W przypadku naruszenia zabezpieczeń komputera zdalnego osoba atakująca ma dostęp do poświadczeń użytkownika. Protokół CredSSP jest domyślnie wyłączony na komputerach klienckich i serwerowych. Należy włączyć protokół CredSSP tylko w najbardziej zaufanych środowiskach. Na przykład administrator domeny nawiązujący połączenie z kontrolerem domeny może mieć włączoną usługę CredSSP, ponieważ kontroler domeny jest wysoce zaufany.
Należy włączyć protokół CredSSP zarówno na komputerze inicjującym, nazywanym klientem, jak i na komputerze odbierającym, nazywanym serwerem. Dzięki temu komputer odbierający może delegować poświadczenie jednego dodatkowego przeskoku.
Aby skonfigurować klienta, uruchom następujące polecenie, podstawiając servername nazwą serwera, który będzie mógł ponownie delegować poświadczenia.
Enable-WsManCredSSP –Role Client –Delegate servername
Nazwa serwera może zawierać symbole wieloznaczne. Jednak użycie symbolu wieloznakowego gwiazdki (*) jest zbyt permissive, ponieważ można umożliwić każdemu komputerowi ponowne usunięcie poświadczeń, nawet nieautoryzowanego użytkownika. Zamiast tego należy rozważyć ograniczony wzorzec z symbolami wieloznacznymi, taki jak *.ADATUM.com, który ogranicza ponowneleganie komputerów w tej domenie.
Aby skonfigurować serwer, uruchom polecenie Enable-WsManCredSSP –Role Server. Na serwerze nie jest wymagana żadna lista komputerów delegowanych. Te ustawienia można również skonfigurować za pomocą zasad grupy, które oferują bardziej scentralizowaną i spójną konfigurację w przedsiębiorstwie.
Uwaga
Wystąpiło wiele naruszeń zabezpieczeń udokumentowanych podczas korzystania z protokołu CredSSP, dlatego nie jest to już preferowana opcja. Zamiast tego należy użyć ograniczonego delegowania.
Delegowanie ograniczone protokołu Kerberos oparte na zasobach
Począwszy od systemu Windows Server 2012, można z niego korzystać przy użyciu protokołu CredSSP i zamiast tego używać ograniczonego delegowania. Delegowanie ograniczone implementuje delegowanie biletów usługowych, wykorzystując deskryptory zabezpieczeń zamiast listy dozwolonych nazw serwerów. Dzięki temu zasób może określić, którzy podmioty zabezpieczeń mogą żądać biletów w imieniu innego użytkownika. Ograniczone delegowanie oparte na zasobach działa poprawnie niezależnie od poziomu funkcjonalności domeny.
Ograniczone delegowanie wymaga:
- Dostęp do kontrolera domeny w tej samej domenie co komputer hosta, z którego są uruchamiane polecenia komunikacji zdalnej programu Windows PowerShell.
- Dostęp do kontrolera domeny w domenie hostująca serwer zdalny, do którego próbujesz uzyskać dostęp z pośredniego serwera zdalnego.
Kod konfigurowania uprawnień wymaga komputera z systemem Windows Server z narzędziami administracji zdalnej serwera programu PowerShell (RSAT) usługi Active Directory. Funkcję RSAT można dodać jako funkcję systemu Windows, uruchamiając następujące dwa polecenia:
Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Aby udzielić delegowania opartego na zasobach, ograniczonego delegowania protokołu Kerberos z LON-SVR1 poprzez LON-SVR2 do LON-SVR3, uruchom następujące polecenie:
Set-ADComputer -Identity LON-SVR2 -PrincipalsAllowedToDelegateToAccount LON-SVR3
Jeden problem może spowodować niepowodzenie tego polecenia. Centrum dystrybucji kluczy (KDC) ma 15-minutową ujemną pamięć podręczną SPN. Jeśli LON-SVR2 próbował już komunikować się z LON-SVR3, istnieje negatywny wpis pamięci podręcznej. Należy wyczyścić pamięć podręczną w systemie LON-SVR2 przy użyciu jednej z następujących technik:
- Uruchom polecenie
klist purge -li 0x3e7. Jest to preferowana i najszybsza metoda. - Poczekaj 15 minut na automatyczne wyczyszczenie pamięci podręcznej.
- Uruchom ponownie LON-SVR2.
Aby przetestować ograniczone delegowanie, uruchom następujący przykład kodu:
$cred = Get-Credential Adatum\TestUser
Invoke-Command -ComputerName LON-SVR1.Name -Credential $cred -ScriptBlock {Test-Path \\$($using:ServerC.Name)\C$ `
Get-Process lsass -ComputerName $($using:LON-SVR2.Name)
Get-EventLog -LogName System -Newest 3 -ComputerName $using:LON-SVR3.Name
}
Wystarczy administrować
Just Enough Administration (JEA) to technologia zabezpieczeń, która umożliwia delegowanie administracji dla wszystkich elementów zarządzanych przez program PowerShell. Za pomocą narzędzia JEA można wykonywać następujące czynności:
- Zmniejsz liczbę administratorów na maszynach przy użyciu kont wirtualnych lub kont usług zarządzanych przez grupę w celu wykonywania uprzywilejowanych akcji w imieniu zwykłych użytkowników.
- Ogranicz możliwości użytkowników, określając polecenia cmdlet, funkcje i polecenia zewnętrzne, które mogą uruchamiać.
- Lepiej zrozumieć, co robią użytkownicy, przeglądając transkrypcje i dzienniki, które przedstawiają dokładnie te polecenia, które użytkownik uruchomił podczas sesji.
Wysoce uprzywilejowane konta używane do administrowania serwerami stanowią poważne zagrożenie bezpieczeństwa. Jeśli osoba atakująca naruszy jedną z tych kont, może uruchomić ataki boczne w całej organizacji. Każde naruszone konto zapewnia osobie atakującej dostęp do jeszcze większej liczby kont i zasobów i przybliża je o krok do kradzieży wpisów tajnych firmy, uruchamiania ataku typu "odmowa usługi" (DOS) i nie tylko.
Nie zawsze łatwo jest usunąć uprawnienia administracyjne. Rozważmy typowy scenariusz, w którym rola DNS jest zainstalowana na tej samej maszynie co kontroler domeny usługi Active Directory. Administratorzy DNS wymagają uprawnień administratora lokalnego, aby rozwiązać problemy z serwerem DNS. W tym celu należy jednak uczynić ich członkami grupy zabezpieczeń Administratorzy z wysokimi uprawnieniami. Takie podejście skutecznie daje administratorom DNS możliwość kontrolowania całej domeny i dostępu do wszystkich zasobów na tym komputerze.
JeA rozwiązuje ten problem za pomocą zasady najniższych uprawnień. Za pomocą narzędzia JEA można skonfigurować punkt końcowy zarządzania dla administratorów DNS, który zapewnia im dostęp tylko do poleceń programu PowerShell, które muszą wykonać swoje zadanie. Oznacza to, że można zapewnić odpowiedni dostęp do naprawy zatrutej pamięci podręcznej DNS lub ponownego uruchomienia serwera DNS bez przypadkowego udzielenia im praw do usługi Active Directory lub przeglądania systemu plików lub uruchamiania potencjalnie niebezpiecznych skryptów. Jeszcze lepiej, gdy sesja JEA jest skonfigurowana do używania tymczasowych, uprzywilejowanych kont wirtualnych, administratorzy DNS mogą łączyć się z serwerem przy użyciu poświadczeń innych niż administrator i nadal uruchamiać polecenia, które zwykle wymagają uprawnień administratora. JeA umożliwia usunięcie użytkowników z szeroko uprzywilejowanych ról administratora lokalnego lub domeny i dokładne kontrolowanie tego, co mogą robić na każdej maszynie.
JeA to funkcja dostępna w programie PowerShell 5.0 i nowszych. Aby uzyskać pełną funkcjonalność, należy zainstalować najnowszą wersję programu PowerShell dostępną dla systemu. Komunikacja zdalna programu PowerShell zapewnia podstawę, na której jest kompilowana usługa JEA. Przed użyciem narzędzia JEA należy upewnić się, że komunikacja zdalna programu PowerShell jest włączona i prawidłowo zabezpieczona.
Podczas tworzenia punktu końcowego JEA należy zdefiniować co najmniej jedną funkcję roli, która opisuje, co ktoś może zrobić w sesji JEA. Funkcja roli to plik danych programu PowerShell z rozszerzeniem psrc, który zawiera listę wszystkich poleceń cmdlet, funkcji, dostawców i programów zewnętrznych udostępnianych do łączenia użytkowników.
Nowy plik funkcji roli programu PowerShell można utworzyć za pomocą polecenia cmdlet New-PSRoleCapabilityFile . Następnie należy edytować wynikowy plik możliwości roli, aby zezwolić na polecenia wymagane dla roli. Dokumentacja pomocy programu PowerShell zawiera kilka przykładów sposobu konfigurowania pliku.