Beveiligingsoverwegingen voor externe communicatie van PowerShellPowerShell Remoting Security Considerations

Externe communicatie van PowerShell is de aanbevolen manier voor het beheren van Windows-systemen.PowerShell Remoting is the recommended way to manage Windows systems. Externe communicatie van PowerShell is standaard ingeschakeld in Windows Server 2012 R2.PowerShell Remoting is enabled by default in Windows Server 2012 R2. Dit document bevat informatie over beveiligingsproblemen, aanbevelingen en best practices wanneer u externe communicatie van PowerShell.This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.

Wat is PowerShell voor externe toegang?What is PowerShell Remoting?

Externe communicatie van PowerShell gebruikt Windows Remote Management (WinRM), dit is de Microsoft-implementatie van de Web Services for Management (WS-Management) protocol, zodat gebruikers kunnen uitvoeren van PowerShell de opdrachten op externe computers.PowerShell Remoting uses Windows Remote Management (WinRM), which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol, to allow users to run PowerShell commands on remote computers. U vindt meer informatie over het gebruik van PowerShell voor externe toegang op externe opdrachten uitgevoerd.You can find more information about using PowerShell Remoting at Running Remote Commands.

Externe communicatie van PowerShell is niet hetzelfde als het gebruik van de ComputerName parameter van een cmdlet uit te voeren op een externe computer waarop Remote Procedure Call (RPC) gebruikt als het onderliggende protocol.PowerShell Remoting is not the same as using the ComputerName parameter of a cmdlet to run it on a remote computer, which uses Remote Procedure Call (RPC) as its underlying protocol.

Standaardinstellingen voor externe communicatie van PowerShellPowerShell Remoting default settings

Externe communicatie van PowerShell (en WinRM) luisteren op de volgende poorten:PowerShell Remoting (and WinRM) listen on the following ports:

  • HTTP: 5985HTTP: 5985
  • HTTPS: 5986HTTPS: 5986

Standaard toelaat externe communicatie van PowerShell alleen verbindingen van leden van de groep Administrators.By default, PowerShell Remoting only allows connections from members of the Administrators group. Sessies worden gestart in de context van de gebruiker, zodat alle besturingssysteem toegangsbeheer op afzonderlijke gebruikers toegepast en groepen blijven toepassen op terwijl via externe communicatie van PowerShell is verbonden.Sessions are launched under the user's context, so all operating system access controls applied to individual users and groups continue to apply to them while connected over PowerShell Remoting.

De standaardregel voor Windows Firewall voor externe communicatie van PowerShell accepteert op particuliere netwerken, alle verbindingen.On private networks, the default Windows Firewall rule for PowerShell Remoting accepts all connections. De standaardregel voor Windows Firewall kunt op openbare netwerken externe communicatie van PowerShell verbindingen alleen via binnen hetzelfde subnet.On public networks, the default Windows Firewall rule allows PowerShell Remoting connections only from within the same subnet. U moet expliciet wijzigen die regel voor het openen van PowerShell voor externe toegang op alle verbindingen van een openbaar netwerk.You have to explicitly change that rule to open PowerShell Remoting to all connections on a public network.

Waarschuwing: de firewallregel voor openbare netwerken is bedoeld om de computer beschermen tegen mogelijk schadelijke externe verbindingspogingen.Warning: The firewall rule for public networks is meant to protect the computer from potentially malicious external connection attempts. Wees voorzichtig bij het verwijderen van deze regel.Use caution when removing this rule.

Geïsoleerde processenProcess isolation

Externe communicatie van PowerShell gebruikt Windows Remote Management (WinRM) voor communicatie tussen computers.PowerShell Remoting uses Windows Remote Management (WinRM) for communication between computers. WinRM wordt uitgevoerd als een service onder het account Network Service en geïsoleerde processen die worden uitgevoerd als gebruikersaccounts aan host PowerShell exemplaren gestart.WinRM runs as a service under the Network Service account, and spawns isolated processes running as user accounts to host PowerShell instances. Een exemplaar van PowerShell uitgevoerd als een gebruiker heeft geen toegang tot een proces dat een exemplaar van PowerShell uitgevoerd als een andere gebruiker.An instance of PowerShell running as one user has no access to a process running an instance of PowerShell as another user.

Gebeurtenislogboeken gegenereerd door externe communicatie van PowerShellEvent logs generated by PowerShell Remoting

FireEye is een goed overzicht van de gebeurtenislogboeken en andere beveiligingsbewijs gegenereerd door externe communicatie van PowerShell-sessies, beschikbaar op opgegevenFireEye has provided a good summary of the event logs and other security evidence generated by PowerShell Remoting sessions, available at
PowerShell onderzoeken aanvallen.Investigating PowerShell Attacks.

Versleuteling en transportprotocollenEncryption and transport protocols

Is het handig om de beveiliging van een externe communicatie van PowerShell-verbinding vanuit twee perspectieven: initiële verificatie en voortdurend communiceren.It is helpful to consider the security of a PowerShell Remoting connection from two perspectives: initial authentication, and ongoing communication.

Ongeacht het transportprotocol gebruikt (HTTP of HTTPS) versleutelt externe communicatie van PowerShell altijd alle communicatie na de eerste verificatie met een per-AES-256 symmetrische sessiesleutel.Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key.

Eerste verificatieInitial authentication

Verificatie bevestigt de identiteit van de client bij de server- en in het ideale geval - de server naar de client.Authentication confirms the identity of the client to the server - and ideally - the server to the client.

Wanneer een client verbinding maakt met een domeinserver met de naam van de computer (dat wil zeggen: server01, of server01.contoso.com), is het standaardverificatieprotocol Kerberos.When a client connects to a domain server using its computer name (i.e.: server01, or server01.contoso.com), the default authentication protocol is Kerberos. Kerberos wordt gegarandeerd dat de gebruikers-id en de identiteit van server zonder een soort herbruikbare referenties te verzenden.Kerberos guarantees both the user identity and server identity without sending any sort of reusable credential.

Wanneer een client verbinding maakt met de domeinserver van een met behulp van het IP-adres of verbinding met een werkgroepserver is maakt, is Kerberos-verificatie niet mogelijk.When a client connects to a domain server using its IP address, or connects to a workgroup server, Kerberos authentication is not possible. In dat geval PowerShell voor externe toegang is afhankelijk van de NTLM-verificatieprotocol.In that case, PowerShell Remoting relies on the NTLM authentication protocol. Het NTLM-verificatieprotocol wordt gegarandeerd dat de identiteit van de gebruiker zonder een soort delegable referentie te verzenden.The NTLM authentication protocol guarantees the user identity without sending any sort of delegable credential. Om te bewijzen dat gebruikers-id, het NTLM-protocol is vereist dat de client en de server een sessiesleutel van het wachtwoord van de gebruiker berekenen zonder ooit uitwisselen van het wachtwoord zelf.To prove user identity, the NTLM protocol requires that both the client and server compute a session key from the user's password without ever exchanging the password itself. De server normaal gesproken weet niet het wachtwoord van de gebruiker, zodat deze communiceert met de domeincontroller de gebruiker het wachtwoord en berekent de sessiesleutel voor de server.The server typically does not know the user's password, so it communicates with the domain controller, which does know the user's password and calculates the session key for the server.

Het NTLM-protocol wordt echter niet, gegarandeerd dat de identiteit van server.The NTLM protocol does not, however, guarantee server identity. Net als bij alle protocollen die gebruikmaken van NTLM voor verificatie, kan de domeincontroller voor het berekenen van een sessiesleutel NTLM en waardoor imiteren van de server worden aangeroepen door een kwaadwillende persoon met toegang tot een domein van het computeraccount.As with all protocols that use NTLM for authentication, an attacker with access to a domain-joined computer's machine account could invoke the domain controller to compute an NTLM session-key and thereby impersonate the server.

Op basis van NTLM-verificatie is standaard uitgeschakeld, maar kan worden toegestaan door beide SSL configureren op de doelserver, of door het configureren van de WinRM-TrustedHosts-instelling op de client.NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on the target server, or by configuring the WinRM TrustedHosts setting on the client.

Met behulp van SSL-certificaten voor het valideren van de identiteit van server tijdens verbindingen op basis van NTLMUsing SSL certificates to validate server identity during NTLM-based connections

Aangezien het NTLM-verificatieprotocol kan niet Zorg ervoor dat de identiteit van de doelserver (maar wel dat dit uw wachtwoord al kent), kunt u de doelservers om SSL te gebruiken voor externe communicatie van PowerShell kunt configureren.Since the NTLM authentication protocol cannot ensure the identity of the target server (only that it already knows your password), you can configure target servers to use SSL for PowerShell Remoting. Een SSL-certificaat toewijzen aan de doelserver (indien uitgegeven door een certificeringsinstantie die door de client ook vertrouwd), kunt NTLM-verificatie die wordt gegarandeerd dat de gebruikers-id en de identiteit van server.Assigning a SSL certificate to the target server (if issued by a Certificate Authority that the client also trusts) enables NTLM-based authentication that guarantees both the user identity and server identity.

NTLM-gebaseerde server identity-fouten worden genegeerdIgnoring NTLM-based server identity errors

Als het implementeren van een SSL-certificaat op een server voor NTLM-verbindingen onbruikbare is, mag u de resulterende identiteit fouten onderdrukken door de server toe te voegen aan de WinRM TrustedHosts lijst.If deploying a SSL certificate to a server for NTLM connections is infeasible, you may suppress the resulting identity errors by adding the server to the WinRM TrustedHosts list. Houd er rekening mee dat de naam van een server toe te voegen aan de lijst TrustedHosts moet niet worden beschouwd als een vorm van instructie van de betrouwbaarheid van de hosts zelf - als het NTLM-verificatieprotocol kan niet worden gegarandeerd dat u in feite een verbinding met de host verbinding maken met wilde.Please note that adding a server name to the TrustedHosts list should not be considered as any form of statement of the trustworthiness of the hosts themselves - as the NTLM authentication protocol cannot guarantee that you are in fact connecting to the host you are intending to connect to. In plaats daarvan moet u de instelling TrustedHosts aan de lijst met hosts die u onderdrukken van de fout is gegenereerd wilt door het controleren van de identiteit van de server niet kan worden.Instead, you should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated by being unable to verify the server's identity.

Voortdurend communicerenOngoing Communication

Zodra de eerste verificatie is voltooid, de PowerShell Remoting Protocol versleutelt alle verdere communicatie met een per-AES-256 symmetrische sessiesleutel.Once initial authentication is complete, the PowerShell Remoting Protocol encrypts all ongoing communication with a per-session AES-256 symmetric key.

De tweede hop makenMaking the second hop

Standaard PowerShell voor externe toegang maakt gebruik van Kerberos (indien beschikbaar) of NTLM voor verificatie.By default, PowerShell Remoting uses Kerberos (if available) or NTLM for authentication. Beide van deze protocollen worden geverifieerd bij de externe computer zonder referenties te verzenden aan.Both of these protocols authenticate to the remote machine without sending credentials to it. Dit is de veiligste manier om te verifiëren, maar omdat de externe computer geen referenties van de gebruiker deze geen toegang tot andere computers en services namens de gebruiker.This is the most secure way to authenticate, but because the remote machine does not have the user's credentials, it cannot access other computers and services on the user's behalf. Dit staat bekend als de "tweede hop '-probleem.This is known as the "second hop problem".

Er zijn verschillende manieren om dit probleem te voorkomen.There are several ways to avoid this problem. Zie voor beschrijvingen van deze methoden en de voor- en nadelen van elke maken van de tweede hop in externe communicatie van PowerShell.For descriptions of these methods, and the pros and cons of each, see Making the second hop in PowerShell Remoting.