Megosztás a következőn keresztül:

Biztonsági szempontok a PowerShell-újramotáláshoz a WinRM használatával

A Windows rendszerek felügyeletére az ajánlott módszer a PowerShell távoli elérés. A PowerShell-újraküldés alapértelmezés szerint engedélyezve van a Windows Server 2012 R2 és újabb verziókban. Ez a dokumentum a PowerShell-remoting használatakor felmerülő biztonsági problémákat, javaslatokat és ajánlott eljárásokat ismerteti.

Mi az a PowerShell Remoting?

A PowerShell remoting Windows Remote Management (WinRM) használatával teszi lehetővé a felhasználók számára a PowerShell-parancsok távoli számítógépeken való futtatását. A WinRM a Web Services for Management (WS-Management) protokoll Microsoft-implementációja. A PowerShell-remoting használatáról további információt Távoli parancsok futtatásacímű témakörben talál.

A PowerShell-távvezérlés nem azonos azzal, amikor a parancsmag ComputerName paraméterét használjuk, hogy egy távoli számítógépen futtassuk, amely a távoli eljáráshívás (RPC) protokollját használja alapértelmezettként.

A PowerShell távoli kapcsolat alapértelmezett beállításai

A WinRM-et tartalmazó PowerShell-remoting a következő portokat figyeli:

  • HTTP: 5985
  • HTTPS: 5986

Alapértelmezés szerint a PowerShell-távoli kapcsolat csak a Rendszergazdák csoport tagjai számára engedélyez kapcsolatokat. A munkamenetek a felhasználó környezetében indulnak el, így az egyes felhasználókra és csoportokra alkalmazott összes operációs rendszer hozzáférés-vezérlési megoldása továbbra is érvényes marad, miközben a PowerShell-távoli kapcsolaton keresztül csatlakoznak hozzájuk.

Magánhálózatokon a PowerShell-remoting alapértelmezett Windows tűzfalszabálya minden kapcsolatot elfogad. Nyilvános hálózatokon az alapértelmezett Windows tűzfalszabály csak az ugyanazon alhálózatból érkező PowerShell-távoli kapcsolatok engedélyezését teszi lehetővé. Kifejezetten módosítania kell ezt a szabályt, hogy a PowerShell-remotingot megnyissa a nyilvános hálózaton lévő összes kapcsolatra.

Figyelmeztetés

A nyilvános hálózatok tűzfalszabályának célja, hogy megvédje a számítógépet a potenciálisan rosszindulatú külső kapcsolati kísérletektől. A szabály eltávolításakor körültekintően járjon el.

Folyamatelkülönítés

A PowerShell-remoting a WinRM-et használja a számítógépek közötti kommunikációhoz. A WinRM szolgáltatásként fut a Hálózati szolgáltatás fiók alatt, és a PowerShell-példányok üzemeltetéséhez felhasználói fiókként futó izolált folyamatokat hoz létre. Az egyik felhasználóként futó PowerShell-példánynak nincs hozzáférése a PowerShell egy példányát másik felhasználóként futtató folyamathoz.

A PowerShell távirányítás által létrehozott eseménynaplók

A Mandiant kutatói előadást mutattak be a BlackHat konferencián, amely jól összefoglalja az eseménynaplókat és a PowerShell remoting munkamenetek által létrehozott egyéb biztonsági bizonyítékokat. További információért lásd: PowerShell-támadások kivizsgálása.

Titkosítási és átviteli protokollok

Hasznos, ha két szemszögből tekinti át a PowerShell-remoting kapcsolat biztonságát: a kezdeti hitelesítést és a folyamatos kommunikációt.

A használt átviteli protokolltól (HTTP vagy HTTPS) függetlenül a WinRM mindig titkosítja az összes PowerShell-remoting kommunikációt a kezdeti hitelesítés után.

Kezdeti hitelesítés

A hitelesítés megerősíti az ügyfél identitását a kiszolgálónak – és ideális esetben – az ügyfélnek.

Amikor egy ügyfél a számítógép nevével csatlakozik egy tartománykiszolgálóhoz, az alapértelmezett hitelesítési protokoll Kerberos. A Kerberos a felhasználói és a kiszolgálóidentitást is garantálja anélkül, hogy bármilyen újrafelhasználható hitelesítő adatot küldene.

Ha egy ügyfél az IP-címével csatlakozik egy tartománykiszolgálóhoz, vagy munkacsoport-kiszolgálóhoz csatlakozik, a Kerberos-hitelesítés nem lehetséges. Ebben az esetben a PowerShell Remoting az NTLM hitelesítési protokollazonosító eljárásra támaszkodik. Az NTLM hitelesítési protokoll garantálja a felhasználói identitást anélkül, hogy bármilyen delegálható hitelesítő adatot küldene. A felhasználói identitás igazolásához az NTLM protokoll megköveteli, hogy az ügyfél és a kiszolgáló is a felhasználó jelszavából számítsa ki a munkamenetkulcsot anélkül, hogy magát a jelszót kicserélte volna. A kiszolgáló általában nem ismeri a felhasználó jelszavát, ezért kommunikál a tartományvezérlővel, amely ismeri a felhasználó jelszavát, és kiszámítja a kiszolgáló munkamenetkulcsát.

Az NTLM protokoll azonban nem garantálja a kiszolgálóidentitást. Az NTLM-et hitelesítéshez használó protokollokhoz hasonlóan a tartományhoz csatlakoztatott számítógép számítógépfiókjának hozzáférésével rendelkező támadók meghívhatják a tartományvezérlőt egy NTLM-munkamenetkulcs kiszámításához és a kiszolgáló megszemélyesítéséhez.

Az NTLM-alapú hitelesítés alapértelmezés szerint le van tiltva. Az NTLM engedélyezéséhez konfigurálhatja az SSL-t a célkiszolgálón, vagy konfigurálhatja a WinRM TrustedHosts beállítást az ügyfélen.

Ssl-tanúsítványok használata a kiszolgálóidentitás ellenőrzéséhez az NTLM-alapú kapcsolatok során

Mivel az NTLM hitelesítési protokoll nem tudja biztosítani a célkiszolgáló identitását (csak azt, hogy már ismeri a jelszavát), a célkiszolgálók úgy konfigurálhatók, hogy SSL-t használjanak a PowerShell-újraküldéshez. Ssl-tanúsítvány hozzárendelése a célkiszolgálóhoz (ha egy hitelesítésszolgáltató állítja ki, amelyet az ügyfél is megbízik) lehetővé teszi az NTLM-alapú hitelesítést, amely garantálja a felhasználói identitást és a kiszolgálóidentitást is.

Az NTLM-alapú kiszolgálóidentitási hibák figyelmen kívül hagyása

Ha nem sikerült SSL-tanúsítványt üzembe helyezni egy kiszolgálón az NTLM-kapcsolatokhoz, a kiszolgáló WinRM TrustedHosts listához való hozzáadásával letilthatja az ebből eredő identitáshibákat. Ha egy kiszolgálónevet ad hozzá a TrustedHosts listához, az nem tekinthető a gazdagépek megbízhatóságának bármilyen állításaként, mivel az NTLM hitelesítési protokoll nem garantálja, hogy valójában a szándékában álló gazdagéphez csatlakozik. Ehelyett a TrustedHosts beállítást kell tekintenie azon gazdagépek listájának, amelyek esetében el szeretné tiltani a létrehozott hibát, mivel nem tudja ellenőrizni a kiszolgáló identitását.

Folyamatos kommunikáció

A kezdeti hitelesítés befejezése után a WinRM titkosítja a folyamatban lévő kommunikációt. AMIKOR HTTPS-en keresztül csatlakozik, a WinRM a TLS protokoll használatával egyezteti az adatok átviteléhez használt titkosítást. HA HTTP-en keresztül csatlakozik, a WinRM a kezdeti hitelesítési protokoll által egyeztetett üzenetszintű titkosítást használja.

  • Az alapszintű hitelesítés nem biztosít titkosítást.
  • Az NTLM-hitelesítés egy 128 bites kulccsal rendelkező RC4-titkosítást használ.
  • A TGS-jegy etype határozza meg a Kerberos-hitelesítés titkosítását. Ez az AES-256 a modern rendszereken.
  • A CredSSP-titkosítás a kézfogásban tárgyalt TLS-titkosítási csomagot használja.

A második ugrás végrehajtása

A PowerShell-remoting alapértelmezés szerint Kerberost (ha van) vagy NTLM-et használ a hitelesítéshez. Mindkét protokoll hitelesítő adatok küldése nélkül hitelesíti a távoli gépet. Ez a hitelesítés legbiztonságosabb módja, de mivel a távoli gép nem rendelkezik a felhasználó hitelesítő adataival, nem tud hozzáférni más számítógépekhez és szolgáltatásokhoz a felhasználó nevében. Ez az úgynevezett második ugrási probléma.

Ezt a problémát többféleképpen is elkerülheti. Ezeknek a módszereknek a leírásáért, valamint az egyes módszerek előnyeiért és hátrányaiért lásd: A második lépés a PowerShell távtávvezérlésben.

Hivatkozások