Granska säkerhetsfunktionen för fjärrstyrning i Windows PowerShell
Som standard tillåter slutpunkterna som Windows PowerShell skapar endast anslutningar av medlemmar i en viss grupp. Från och med Windows Server 2016 och Windows 10 omfattar dessa grupper gruppen Fjärrhanteringsanvändare och den lokala gruppen Administratörer. I en Active Directory Domain Services (AD DS)-domän inkluderar den senare även medlemmar i den global gruppen Domänadministratörer, eftersom denna grupp är medlem i den lokala gruppen Administratörer på varje domänansluten dator. Som standard, före Windows Server 2016 och Windows 10, tilläts endast medlemmar i den lokala gruppen Administratörer att använda PowerShell-fjärrstyrning. Det går dock att ändra standardvärdena. Varje slutpunkt har en lista över systemåtkomstkontroll (SACL) som du kan ändra för att styra exakt vem som kan ansluta till den.
PowerShell-fjärrkommunikation och WinRM lyssnar på följande portar:
- HTTP: 5985
- HTTPS: 5986
Standardbeteendet för fjärrkommunikation är att delegera dina inloggningsuppgifter till fjärrdatorn, även om du har möjlighet att ange alternativa autentiseringsuppgifter när du upprättar en anslutning. Fjärrdatorn som du ansluter till använder dessa autentiseringsuppgifter för att personifiera dig och utföra de uppgifter som du har angett med hjälp av dessa autentiseringsuppgifter. Om du har aktiverat granskning, förutom de uppgifter som du utför, kommer även de uppgifter som utförs av PowerShell-fjärrstyrning å dina vägnar att granskas. I själva verket är fjärrkommunikationen säkerhetstransparent och ändrar inte miljöns befintliga säkerhet. Med fjärrstyrning kan du utföra samma uppgifter som du utför när du befinner dig fysiskt framför den lokala datorn.
Anteckning
I privata nätverk är standardregeln för Windows-brandväggen för PowerShell-fjärrkommunikation att acceptera alla anslutningar. I offentliga nätverk tillåter standardregeln för Windows-brandväggen endast PowerShell-fjärrkommunikationsanslutningar från samma undernät. Du måste uttryckligen ändra regeln för att öppna PowerShell-fjärrkommunikation till alla anslutningar i ett offentligt nätverk.
Säkerhetsrisker och ömsesidig autentisering
Att delegera dina autentiseringsuppgifter till en fjärrdator innebär vissa säkerhetsrisker. Om en angripare till exempel personifierar en känd fjärrdator kan du potentiellt överföra mycket privilegierade autentiseringsuppgifter till angriparen, som sedan kan använda dem i skadliga syften. På grund av den här risken kräver fjärrkommunikation som standard ömsesidig autentisering, vilket innebär att du måste autentisera dig mot fjärrdatorn, och att fjärrdatorn också måste autentisera sig mot dig. Den här ömsesidiga autentiseringen garanterar att du endast ansluter till den exakta dator som du avsåg.
Ömsesidig autentisering är en inbyggd funktion i Active Directory Kerberos-autentiseringsprotokollet. När du ansluter mellan betrodda domändatorer sker ömsesidig autentisering automatiskt. När du ansluter till icke-domänanslutna datorer måste du ange en annan form av ömsesidig autentisering i form av ett SSL-certifikat och HTTPS-protokollet som måste konfigureras i förväg. Ett annat alternativ är att inaktivera kravet på ömsesidig autentisering genom att lägga till fjärrdatorn i din lokala TrustedHosts-lista. Observera dock att TrustedHosts använder NTLM-autentisering (Windows NT LAN Manager), vilket inte säkerställer serveridentiteten. Precis som med alla protokoll som använder NTLM för autentisering kan angripare som har åtkomst till en domänansluten dators betrodda konto få domänkontrollanten att skapa en NTLM-sessionsnyckel och därmed personifiera servern.
Anteckning
NTLM-autentiseringsprotokollet kan inte säkerställa målserverns identitet. det kan bara se till att det redan känner till ditt lösenord. Därför bör du konfigurera målservrar för att använda SSL för PowerShell-fjärrkommunikation. Att hämta ett SSL-certifikat utfärdat av en betrodd certifikatutfärdare som klienten litar på och tilldela det till målservern förbättrar säkerheten för den NTLM-baserade autentiseringen, vilket hjälper till att verifiera både användaridentiteten och serveridentiteten.
Överväganden för datornamn
För att AD DS-baserad autentisering ska fungera måste PowerShell-fjärrkommunikation kunna söka efter och hämta Active Directory-domän Services-datorobjekt (AD DS). Det innebär att du måste referera till måldatorer med hjälp av deras fullständigt kvalificerade domännamn (FQDN). IP-adresser eller DNS-alias (Domain Name System) fungerar till exempel inte eftersom de inte tillhandahåller fjärrkommunikation med den ömsesidiga autentisering som krävs. Om du måste referera till en dator med en IP-adress eller ett DNS-alias måste du ansluta med HTTPS, vilket innebär att fjärrdatorn måste konfigureras för att acceptera det protokollet. Du måste också lägga till IP-adressen eller DNS-aliaset i din lokala TrustedHosts-lista.
Anteckning
Ett särskilt undantag görs för datornamnet localhost, som gör att du kan använda det för att ansluta till den lokala datorn utan några andra konfigurationsändringar. Om den lokala datorn använder ett klientbaserat operativsystem måste WinRM konfigureras på den.
Listan över betrodda värdar
TrustedHosts-listan är en lokalt konfigurerad inställning som du också kan konfigurera med hjälp av ett gruppolicyobjekt (GPO). Listan TrustedHosts räknar upp de datorer för vilka ömsesidig autentisering inte är möjlig. Datorer måste anges med samma namn som du använder för att ansluta till dem, oavsett om det är det faktiska datornamnet, ett DNS-alias eller en IP-adress. Du kan använda jokertecken för att ange SRV*, vilket gör att alla datorer vars namn eller DNS-alias börjar med SRV kan ansluta. Var dock försiktig med den här listan. Listan TrustedHosts gör det enklare att ansluta till icke-domändatorer utan att behöva konfigurera HTTPS, men kringgår en viktig säkerhetsåtgärd. Det gör att du kan skicka dina autentiseringsuppgifter till en fjärrdator utan att avgöra om den datorn i själva verket är en som du avsåg att ansluta till. Du bör endast använda listan TrustedHosts för att ange datorer som du inte vet ska komprometteras, till exempel servrar som finns i ett skyddat datacenter. Du kan också använda TrustedHosts för att tillfälligt aktivera anslutningar till icke-domändatorer i ett kontrollerat nätverksundernät, till exempel nya datorer som genomgår en etableringsprocess.
Anteckning
Som bästa praxis bör du undvika att använda listan TrustedHosts om det inte är absolut nödvändigt. Att konfigurera en icke-domändator för att använda HTTPS är en säkrare långsiktig lösning.
Sekretess
Som standard använder fjärrkommunikation HTTP, som inte erbjuder sekretess eller kryptering av innehållet i din kommunikation. Windows PowerShell kan dock och tillämpar kryptering på programnivå som standard. Det innebär att din kommunikation får en viss grad av sekretess och skydd. I interna nätverk räcker den här krypteringen på programnivå i allmänhet för att uppfylla organisationens säkerhetskrav.
I en domänmiljö som använder standardprotokollet för Kerberos-autentisering skickas autentiseringsuppgifter i form av krypterade Kerberos-biljetter som inte innehåller lösenord.
När du ansluter med HTTPS krypteras hela kanalen med hjälp av krypteringsnycklarna för fjärrdatorns SSL-certifikat. Även om du använder Grundläggande autentisering överförs därför inte lösenord i klartext. Men när du ansluter med HTTP- och Basic-autentisering till en dator som inte har konfigurerats för HTTPS överförs autentiseringsuppgifterna (inklusive lösenord) i klartext. Detta kan till exempel inträffa när du ansluter till en icke-domändator som du lägger till i din lokala TrustedHosts-lista. Detta kan även inträffa när du använder en domänansluten dator genom att ange dess IP-adress i stället för dess värdnamn.
Eftersom autentiseringsuppgifterna överförs i klartext i det scenariot bör du se till att du ansluter till en icke-domändator endast på ett kontrollerat och skyddat nätverksundernät, till exempel ett specifikt avsett för ny datoretablering. Om du rutinmässigt måste ansluta till en icke-domändator bör du konfigurera den så att den stöder HTTPS.