Dela via

Säkerhetsöverväganden för PowerShell-fjärrkommunikation med WinRM

  • Artikel

PowerShell-fjärrkommunikation är det rekommenderade sättet att hantera Windows-system. PowerShell-fjärrkommunikation är aktiverat som standard i Windows Server 2012 R2 och senare. Det här dokumentet beskriver säkerhetsproblem, rekommendationer och metodtips när du använder PowerShell-fjärrkommunikation.

Vad är PowerShell-fjärrkommunikation?

PowerShell-fjärrkommunikation använder Windows Remote Management (WinRM) för att tillåta användare att köra PowerShell-kommandon på fjärrdatorer. WinRM är Microsofts implementering av WS-Management-protokollet (Web Services for Management). Mer information om hur du använder PowerShell-fjärrkommunikation finns i Köra fjärrkommandon.

PowerShell-fjärrkommunikation är inte detsamma som att använda parametern ComputerName för en cmdlet för att köra den på en fjärrdator, som använder RPC (Remote Procedure Call) som sitt underliggande protokoll.

Standardinställningar för PowerShell-fjärrkommunikation

PowerShell-fjärrkommunikation (och WinRM) lyssnar på följande portar:

  • HTTP: 5985
  • HTTPS: 5986

Som standard tillåter PowerShell-fjärrkommunikation endast anslutningar från medlemmar i gruppen Administratörer. Sessioner startas under användarens kontext, så alla åtkomstkontroller för operativsystem som tillämpas på enskilda användare och grupper fortsätter att gälla för dem när de är anslutna via PowerShell-fjärrkommunikation.

I privata nätverk accepterar standardregeln för Windows-brandväggen för PowerShell-fjärrkommunikation 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.

Varning

Brandväggsregeln för offentliga nätverk är avsedd att skydda datorn från potentiellt skadliga externa anslutningsförsök. Var försiktig när du tar bort den här regeln.

Processisolering

PowerShell-fjärrkommunikation använder WinRM för kommunikation mellan datorer. WinRM körs som en tjänst under nätverkstjänstkontot och skapar isolerade processer som körs som användarkonton som värd för PowerShell-instanser. En instans av PowerShell som körs som en användare har ingen åtkomst till en process som kör en instans av PowerShell som en annan användare.

Händelseloggar som genereras av PowerShell-fjärrkommunikation

FireEye har gett en bra sammanfattning av händelseloggarna och andra säkerhetsbevis som genereras av PowerShell-fjärrkommunikationssessioner, som finns i Undersöka PowerShell-attacker.

Krypterings- och transportprotokoll

Det är bra att tänka på säkerheten för en PowerShell-fjärrkommunikationsanslutning ur två perspektiv: inledande autentisering och pågående kommunikation.

Oavsett vilket transportprotokoll som används (HTTP eller HTTPS) krypterar WinRM alltid all PowerShell-fjärrkommunikation efter den första autentiseringen.

Inledande autentisering

Autentisering bekräftar klientens identitet till servern – och helst – servern till klienten.

När en klient ansluter till en domänserver med datornamnet är standardautentiseringsprotokollet Kerberos. Kerberos garanterar både användaridentiteten och serveridentiteten utan att skicka någon form av återanvändbara autentiseringsuppgifter.

När en klient ansluter till en domänserver med sin IP-adress eller ansluter till en arbetsgruppsserver är Kerberos-autentisering inte möjligt. I så fall förlitar sig PowerShell Remoting på NTLM-autentiseringsprotokollet. NTLM-autentiseringsprotokollet garanterar användaridentiteten utan att skicka någon form av delegerbara autentiseringsuppgifter. För att bevisa användaridentiteten kräver NTLM-protokollet att både klienten och servern beräknar en sessionsnyckel från användarens lösenord utan att behöva byta ut själva lösenordet. Servern känner vanligtvis inte till användarens lösenord, så den kommunicerar med domänkontrollanten, som känner till användarens lösenord och beräknar sessionsnyckeln för servern.

NTLM-protokollet garanterar dock inte serveridentitet. Precis som med alla protokoll som använder NTLM för autentisering kan en angripare med åtkomst till en domänansluten dators datorkonto anropa domänkontrollanten för att beräkna en NTLM-sessionsnyckel och därmed personifiera servern.

NTLM-baserad autentisering är inaktiverad som standard, men kan tillåtas genom att antingen konfigurera SSL på målservern eller genom att konfigurera inställningen WinRM TrustedHosts på klienten.

Använda SSL-certifikat för att verifiera serveridentitet under NTLM-baserade anslutningar

Eftersom NTLM-autentiseringsprotokollet inte kan säkerställa målserverns identitet (endast att den redan känner till lösenordet) kan du konfigurera målservrar att använda SSL för PowerShell-fjärrkommunikation. Att tilldela ett SSL-certifikat till målservern (om det utfärdas av en certifikatutfärdare som klienten också litar på) möjliggör NTLM-baserad autentisering som garanterar både användaridentiteten och serveridentiteten.

Ignorera NTLM-baserade serveridentitetsfel

Om det inte går att distribuera ett SSL-certifikat till en server för NTLM-anslutningar kan du förhindra de resulterande identitetsfelen genom att lägga till servern i listan WinRM TrustedHosts . Observera att tillägg av ett servernamn i listan TrustedHosts inte bör betraktas som någon form av instruktion om själva värdarnas tillförlitlighet eftersom NTLM-autentiseringsprotokollet inte kan garantera att du faktiskt ansluter till värden som du tänker ansluta till. I stället bör du betrakta inställningen TrustedHosts som en lista över värdar som du vill förhindra felet som genereras genom att inte kunna verifiera serverns identitet.

Löpande kommunikation

När den första autentiseringen är klar krypterar WinRM den pågående kommunikationen. När du ansluter via HTTPS används TLS-protokollet för att förhandla om krypteringen som används för att transportera data. Vid anslutning via HTTP bestäms kryptering på meddelandenivå av det inledande autentiseringsprotokoll som används.

  • Grundläggande autentisering ger ingen kryptering.
  • NTLM-autentisering använder ett RC4-chiffer med en 128-bitarsnyckel.
  • Kerberos-autentiseringskryptering bestäms av etype I TGS-biljetten. Detta är AES-256 på moderna system.
  • CredSSP-kryptering använder TLS-chiffersviten som förhandlades fram i handskakningen.

Gör det andra hoppet

Som standard använder PowerShell-fjärrkommunikation Kerberos (om tillgängligt) eller NTLM för autentisering. Båda dessa protokoll autentiseras till fjärrdatorn utan att skicka autentiseringsuppgifter till den. Det här är det säkraste sättet att autentisera, men eftersom fjärrdatorn inte har användarens autentiseringsuppgifter kan den inte komma åt andra datorer och tjänster för användarens räkning. Detta kallas "second hop-problemet".

Det finns flera sätt att undvika det här problemet. Beskrivningar av dessa metoder och för- och nackdelarna med var och en finns i Making the second hop in PowerShell Remoting (Gör det andra hoppet i PowerShell Remoting).

Referenser