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?

Komunikacja zdalna programu PowerShell używa zdalnego zarządzania systemem Windows (WinRM), aby umożliwić użytkownikom uruchamianie poleceń programu PowerShell na komputerach zdalnych. WinRM to implementacja protokołu Web Services for Management (WS-Management) firmy Microsoft. Więcej informacji na temat komunikacji zdalnej programu PowerShell można znaleźć na stronie Uruchamianie poleceń zdalnych.

Komunikacja zdalna programu PowerShell nie jest taka sama jak używanie parametru ComputerName polecenia cmdlet do uruchamiania go na komputerze zdalnym, który używa zdalnego wywołania procedury (RPC) jako podstawowego protokołu.

Domyślne ustawienia komunikacji zdalnej 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 Administracja istratorów. 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. Należy jawnie zmienić regułę, aby otworzyć zdalne połączenie programu PowerShell ze wszystkimi połączeniami w sieci publicznej.

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 jako usługa na koncie usługi sieciowej i powoduje zduplikowanie izolowanych procesów uruchomionych jako konta użytkowników do hostowania wystąpień programu PowerShell. Wystąpienie programu PowerShell uruchomione jako jeden użytkownik nie ma dostępu do procesu, w którym uruchomiono wystąpienie programu PowerShell jako inny użytkownik.

Dzienniki zdarzeń generowane przez zdalne komunikacja zdalna programu PowerShell

Program FireEye dostarczył dobre podsumowanie dzienników zdarzeń i innych dowodów zabezpieczeń generowanych przez sesje komunikacji zdalnej programu PowerShell dostępne w temacie 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 na serwerze — i najlepiej — serwer klienta.

Gdy klient łączy się z serwerem domeny przy użyciu jego nazwy komputera, domyślnym protokołem uwierzytelniania jest 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 wdrażanie certyfikatu SSL na serwerze dla połączeń NTLM jest niewykonalne, możesz pominąć 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 określane przez etype bilet 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 przeskoku".

Istnieje kilka sposobów, aby uniknąć tego problemu. Opisy tych metod oraz zalety i wady każdej z nich można znaleźć w temacie Making the second hop in PowerShell Remoting (Tworzenie drugiego przeskoku w komunikacji zdalnej programu PowerShell).

Informacje