Udostępnij za pośrednictwem

Zagadnienia dotyczące zabezpieczeń dotyczące komunikacji zdalnej programu PowerShell przy użyciu usługi WinRM

  • Artykuł

Komunikacja zdalna programu PowerShell to zalecany sposób zarządzania systemami Windows. Komunikacja zdalna programu PowerShell jest domyślnie włączona w systemie Windows Server 2012 R2 i nowszym. W tym dokumencie opisano zagadnienia dotyczące zabezpieczeń, zalecenia i najlepsze rozwiązania dotyczące korzystania z komunikacji zdalnej programu PowerShell.

Co to jest komunikacja zdalna programu PowerShell?

Zdalne uruchamianie programu PowerShell używa Windows Remote Management (WinRM), aby umożliwić użytkownikom uruchamianie poleceń programu PowerShell na komputerach zdalnych. WinRM to implementacja Microsoft protokołu Web Services for Management (WS-Management). Więcej informacji na temat komunikacji zdalnej programu PowerShell można znaleźć na stronie Running Remote Commands.

Zdalne zarządzanie PowerShell to nie to samo, co używanie parametru ComputerName polecenia cmdlet do uruchomienia na zdalnym komputerze, które korzysta z protokołu Zdalne Wywołanie Procedury (RPC) jako podstawowego.

Domyślne ustawienia zdalnego zarządzania programu PowerShell

Komunikacja zdalna programu PowerShell (i usługa WinRM) nasłuchuje na następujących portach:

  • HTTP: 5985
  • HTTPS: 5986

Domyślnie komunikacja zdalna programu PowerShell zezwala tylko na połączenia z członkami grupy Administratorzy. Sesje są uruchamiane w kontekście użytkownika, więc wszystkie mechanizmy kontroli dostępu systemu operacyjnego stosowane do poszczególnych użytkowników i grup nadal mają zastosowanie do nich podczas nawiązywania połączenia za pośrednictwem komunikacji zdalnej programu PowerShell.

W sieciach prywatnych domyślna reguła Zapory systemu Windows dla komunikacji zdalnej programu PowerShell akceptuje wszystkie połączenia. W sieciach publicznych domyślna reguła Zapory systemu Windows zezwala na połączenia zdalne programu PowerShell tylko z tej samej podsieci. Aby otworzyć PowerShell Remoting dla wszystkich połączeń w sieci publicznej, musisz wyraźnie zmienić tę regułę.

Ostrzeżenie

Reguła zapory dla sieci publicznych ma chronić komputer przed potencjalnie złośliwymi próbami połączenia zewnętrznego. Zachowaj ostrożność podczas usuwania tej reguły.

Izolacja procesów

Komunikacja zdalna programu PowerShell używa usługi WinRM do komunikacji między komputerami. Usługa WinRM działa na koncie usługi sieciowej i tworzy izolowane procesy uruchamiane na kontach użytkowników w celu hostowania wystąpień programu PowerShell. Wystąpienie programu PowerShell uruchomione przez jednego użytkownika nie ma dostępu do procesu, w którym uruchomiono wystąpienie programu PowerShell przez innego użytkownika.

Dzienniki zdarzeń generowane przez zdalną komunikację programu PowerShell

FireEye dostarczył dobre podsumowanie dzienników zdarzeń i innych dowodów bezpieczeństwa wygenerowanych przez zdalne sesje PowerShell, dostępne w Badanie ataków programu PowerShell.

Protokoły szyfrowania i transportu

Warto rozważyć zabezpieczenia połączenia komunikacji zdalnej programu PowerShell z dwóch perspektyw: uwierzytelnianie początkowe i ciągłą komunikację.

Niezależnie od używanego protokołu transportowego (HTTP lub HTTPS) usługa WinRM zawsze szyfruje całą komunikację zdalną programu PowerShell po początkowym uwierzytelnieniu.

Uwierzytelnianie początkowe

Uwierzytelnianie potwierdza tożsamość klienta do serwera – a idealnie – serwera dla klienta.

Gdy klient łączy się z serwerem domeny przy użyciu jego nazwy komputera, domyślny protokół uwierzytelniania to Kerberos. Protokół Kerberos gwarantuje zarówno tożsamość użytkownika, jak i tożsamość serwera bez wysyłania poświadczeń wielokrotnego użytku.

Gdy klient łączy się z serwerem domeny przy użyciu jego adresu IP lub łączy się z serwerem grupy roboczej, uwierzytelnianie Kerberos nie jest możliwe. W takim przypadku komunikacja zdalna programu PowerShell opiera się na protokole uwierzytelniania NTLM. Protokół uwierzytelniania NTLM gwarantuje tożsamość użytkownika bez wysyłania poświadczeń delegowalnych. Aby udowodnić tożsamość użytkownika, protokół NTLM wymaga, aby zarówno klient, jak i serwer obliczali klucz sesji z hasła użytkownika bez konieczności wymiany samego hasła. Serwer zazwyczaj nie zna hasła użytkownika, dlatego komunikuje się z kontrolerem domeny, który zna hasło użytkownika i oblicza klucz sesji dla serwera.

Protokół NTLM nie gwarantuje jednak tożsamości serwera. Podobnie jak w przypadku wszystkich protokołów, które używają protokołu NTLM do uwierzytelniania, osoba atakująca mająca dostęp do konta komputera przyłączonego do domeny może wywołać kontroler domeny w celu obliczenia klucza sesji NTLM, a tym samym personifikacji serwera.

Uwierzytelnianie oparte na protokole NTLM jest domyślnie wyłączone, ale może być dozwolone przez skonfigurowanie protokołu SSL na serwerze docelowym lub skonfigurowanie ustawienia TrustedHosts usługi WinRM na kliencie.

Używanie certyfikatów SSL do weryfikowania tożsamości serwera podczas połączeń opartych na protokole NTLM

Ponieważ protokół uwierzytelniania NTLM nie może zapewnić tożsamości serwera docelowego (tylko że zna hasło), można skonfigurować serwery docelowe do używania protokołu SSL na potrzeby komunikacji zdalnej programu PowerShell. Przypisanie certyfikatu SSL do serwera docelowego (w przypadku wystawienia przez urząd certyfikacji, któremu ufa również klient) umożliwia uwierzytelnianie oparte na protokole NTLM, które gwarantuje zarówno tożsamość użytkownika, jak i tożsamość serwera.

Ignorowanie błędów tożsamości serwera opartego na protokole NTLM

Jeśli wdrożenie certyfikatu SSL na serwerze dla połączeń NTLM jest niemożliwe, można tymczasowo zignorować wynikowe błędy tożsamości, dodając serwer do listy TrustedHosts usługi WinRM. Należy pamiętać, że dodanie nazwy serwera do listy TrustedHosts nie powinno być traktowane jako żadna forma oświadczenia wiarygodności hostów — ponieważ protokół uwierzytelniania NTLM nie może zagwarantować, że w rzeczywistości łączysz się z hostem, z którym zamierzasz nawiązać połączenie. Zamiast tego należy rozważyć ustawienie TrustedHosts jako listę hostów, dla których chcesz pominąć błąd wygenerowany przez niemożność zweryfikowania tożsamości serwera.

Ciągła komunikacja

Po zakończeniu uwierzytelniania początkowego usługa WinRM szyfruje bieżącą komunikację. Podczas nawiązywania połączenia za pośrednictwem protokołu HTTPS protokół TLS jest używany do negocjowania szyfrowania używanego do transportu danych. Podczas nawiązywania połączenia za pośrednictwem protokołu HTTP szyfrowanie na poziomie komunikatu jest określane przez używany początkowy protokół uwierzytelniania.

  • Uwierzytelnianie podstawowe nie zapewnia szyfrowania.
  • Uwierzytelnianie NTLM używa szyfru RC4 z 128-bitowym kluczem.
  • Szyfrowanie uwierzytelniania Kerberos jest determinowane przez etype w bilecie TGS. Jest to AES-256 w nowoczesnych systemach.
  • Szyfrowanie CredSSP korzysta z zestawu szyfrowania TLS wynegocjowanego w uzgadnianiu.

Wykonywanie drugiego przeskoku

Domyślnie komunikacja zdalna programu PowerShell używa protokołu Kerberos (jeśli jest dostępna) lub NTLM do uwierzytelniania. Oba te protokoły uwierzytelniają się na maszynie zdalnej bez wysyłania do niego poświadczeń. Jest to najbezpieczniejszy sposób uwierzytelniania, ale ponieważ maszyna zdalna nie ma poświadczeń użytkownika, nie może uzyskać dostępu do innych komputerów i usług w imieniu użytkownika. Jest to znane jako "problem z drugim przeskokiem".

Istnieje kilka sposobów, aby uniknąć tego problemu. Opisy tych metod oraz zalety i wady każdej z nich można znaleźć w Realizacja drugiego przeskoku w PowerShell Remoting.

Referencje