Biztonsági szempontok a PowerShell-újramotáláshoz a WinRM használatával
A Windows-rendszerek felügyeletének ajánlott módja a PowerShell-újraformálá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 a 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 távoli parancsok futtatásával kapcsolatos további információk.
A PowerShell-remoting nem ugyanaz, mint amikor egy parancsmag ComputerName paraméterével futtatja azt egy távoli számítógépen, amely a távoli eljáráshívást (RPC) használja alapul szolgáló protokollként.
A PowerShell alapértelmezett beállításainak újraküldése
A PowerShell-remoting (és a WinRM) a következő portokat figyeli:
- HTTP: 5985
- HTTPS: 5986
A PowerShell remoting alapértelmezés szerint csak a Rendszergazda istrators csoport tagjaitól engedélyezi a kapcsolatokat. A munkamenetek a felhasználó környezetében indulnak el, így az egyes felhasználókra és csoportokra alkalmazott összes operációsrendszer-hozzáférés-vezérlés továbbra is érvényes rájuk, miközben a PowerShell-újrakapcsoláson keresztül csatlakozik 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 lehetővé teszi, hogy a PowerShell csak ugyanabból az alhálózatból válassza a kapcsolatokat. Explicit módon módosítania kell ezt a szabályt, hogy megnyissa a PowerShell-remotingotingot egy 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-újraküldés által létrehozott eseménynaplók
A FireEye jó összefoglalást adott az eseménynaplókról és a PowerShell-remoting munkamenetek által létrehozott egyéb biztonsági bizonyítékokról, amelyeket a PowerShell-támadások kivizsgálása során érhet el.
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 a 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 protokollra 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 is meghívhatják a tartományvezérlőt egy NTLM-munkamenetkulcs kiszámításához, és ezáltal megszemélyesíthetik a kiszolgálót.
Az NTLM-alapú hitelesítés alapértelmezés szerint le van tiltva, de az SSL célkiszolgálón való konfigurálásával vagy az ügyfél WinRM TrustedHosts beállításának konfigurálásával engedélyezhető.
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 az SSL-tanúsítvány telepítése nem lehetséges 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 . Vegye figyelembe, hogy a kiszolgáló nevének a TrustedHosts listához való hozzáadása nem tekinthető a gazdagépek megbízhatóságának bármilyen formájának – mivel az NTLM hitelesítési protokoll nem garantálja, hogy valójában ahhoz a gazdagéphez csatlakozik, amelyhez csatlakozni kíván. 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. HTTPS-en keresztüli csatlakozáskor a TLS protokoll használatával egyeztetik az adatok átviteléhez használt titkosítást. HA HTTP-en keresztül csatlakozik, az üzenetszintű titkosítást a használt kezdeti hitelesítési protokoll határozza meg.
- 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 Kerberos-hitelesítés titkosítását a
etypeTGS-jegy határozza meg. 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 a "második ugrási probléma" néven ismert.
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 tekintse meg a Második ugrás készítése a PowerShell-újraírásban című témakört.
