Share via

Beveiligingsoverwegingen voor externe communicatie met PowerShell met Behulp van WinRM

  • Artikel

Externe communicatie met PowerShell is de aanbevolen manier om Windows-systemen te beheren. Externe communicatie via PowerShell is standaard ingeschakeld in Windows Server 2012 R2 en hoger. In dit document worden beveiligingsproblemen, aanbevelingen en aanbevolen procedures behandeld bij het gebruik van externe communicatie met PowerShell.

Wat is externe communicatie met PowerShell?

Externe communicatie van PowerShell maakt gebruik van Windows Remote Management (WinRM) om gebruikers toe te staan PowerShell-opdrachten uit te voeren op externe computers. WinRM is de Microsoft-implementatie van het WS-management-protocol (Web Services for Management). Meer informatie over het gebruik van externe PowerShell-opdrachten vindt u in Externe opdrachten uitvoeren.

Externe communicatie van PowerShell is niet hetzelfde als het gebruik van de parameter ComputerName van een cmdlet om deze uit te voeren op een externe computer, die gebruikmaakt van Remote Procedure Call (RPC) als het onderliggende protocol.

Standaardinstellingen voor externe communicatie in PowerShell

Externe communicatie van PowerShell (en WinRM) luistert op de volgende poorten:

  • HTTP: 5985
  • HTTPS: 5986

Externe toegang van PowerShell staat standaard alleen verbindingen toe van leden van de groep Beheer istrators. Sessies worden gestart in de context van de gebruiker, zodat alle besturingselementen voor toegang van het besturingssysteem die zijn toegepast op afzonderlijke gebruikers en groepen, op hen van toepassing blijven terwijl ze verbonden zijn via externe communicatie via PowerShell.

In privénetwerken accepteert de standaardregel van Windows Firewall voor externe communicatie met PowerShell alle verbindingen. In openbare netwerken staat de standaardregel van Windows Firewall alleen externe verbindingen van PowerShell toe vanuit hetzelfde subnet. U moet die regel expliciet wijzigen om externe communicatie van PowerShell te openen voor alle verbindingen in een openbaar netwerk.

Waarschuwing

De firewallregel voor openbare netwerken is bedoeld om de computer te beschermen tegen mogelijk schadelijke externe verbindingspogingen. Wees voorzichtig bij het verwijderen van deze regel.

Procesisolatie

Externe communicatie van PowerShell maakt gebruik van WinRM voor communicatie tussen computers. WinRM wordt uitgevoerd als een service onder het netwerkserviceaccount en spawns geïsoleerde processen die als gebruikersaccounts worden uitgevoerd om PowerShell-exemplaren te hosten. Een exemplaar van PowerShell dat als één gebruiker wordt uitgevoerd, heeft geen toegang tot een proces waarop een exemplaar van PowerShell als een andere gebruiker wordt uitgevoerd.

Gebeurtenislogboeken gegenereerd door Externe communicatie van PowerShell

FireEye heeft een goed overzicht gegeven van de gebeurtenislogboeken en andere beveiligingsgegevens die zijn gegenereerd door externe PowerShell-sessies, die beschikbaar zijn bij Het onderzoeken van PowerShell-aanvallen.

Versleutelings- en transportprotocollen

Het is handig om vanuit twee perspectieven rekening te houden met de beveiliging van een externe Verbinding met PowerShell: initiële verificatie en doorlopende communicatie.

Ongeacht het gebruikte transportprotocol (HTTP of HTTPS) versleutelt WinRM altijd alle externe communicatie van PowerShell na de eerste verificatie.

Initiële verificatie

Verificatie bevestigt de identiteit van de client aan de server , en idealiter - de server aan de client.

Wanneer een client verbinding maakt met een domeinserver met behulp van de computernaam, is het standaardverificatieprotocol Kerberos. Kerberos garandeert zowel de gebruikersidentiteit als de serveridentiteit zonder een soort herbruikbare referentie te verzenden.

Wanneer een client verbinding maakt met een domeinserver met behulp van het IP-adres of verbinding maakt met een werkgroepserver, is Kerberos-verificatie niet mogelijk. In dat geval is externe communicatie van PowerShell afhankelijk van het NTLM-verificatieprotocol. Het NTLM-verificatieprotocol garandeert de gebruikersidentiteit zonder enige vorm van delegeerbare referentie te verzenden. Om de gebruikersidentiteit te bewijzen, vereist het NTLM-protocol dat zowel de client als de server een sessiesleutel van het wachtwoord van de gebruiker berekent zonder dat het wachtwoord zelf wordt uitgewisseld. De server kent doorgaans het wachtwoord van de gebruiker niet, dus deze communiceert met de domeincontroller, die wel het wachtwoord van de gebruiker kent en de sessiesleutel voor de server berekent.

Het NTLM-protocol garandeert echter geen serveridentiteit. Net als bij alle protocollen die gebruikmaken van NTLM voor verificatie, kan een aanvaller met toegang tot het computeraccount van een domeincomputer de domeincontroller aanroepen om een NTLM-sessiesleutel te berekenen en zo de server te imiteren.

Verificatie op basis van NTLM is standaard uitgeschakeld, maar is mogelijk toegestaan door SSL te configureren op de doelserver of door de instelling WinRM TrustedHosts op de client te configureren.

SSL-certificaten gebruiken om de serveridentiteit te valideren tijdens op NTLM gebaseerde verbindingen

Omdat het NTLM-verificatieprotocol niet kan zorgen voor de identiteit van de doelserver (alleen dat het al uw wachtwoord kent), kunt u doelservers configureren voor het gebruik van SSL voor externe communicatie met PowerShell. Als u een SSL-certificaat toewijst aan de doelserver (indien uitgegeven door een certificeringsinstantie die de client ook vertrouwt), wordt verificatie op basis van NTLM ingeschakeld die zowel de gebruikersidentiteit als de serveridentiteit garandeert.

Op NTLM gebaseerde serveridentiteitsfouten negeren

Als het implementeren van een SSL-certificaat op een server voor NTLM-verbindingen onfeilbaar is, kunt u de resulterende identiteitsfouten onderdrukken door de server toe te voegen aan de winRM TrustedHosts-lijst . Houd er rekening mee dat het toevoegen van een servernaam aan de lijst TrustedHosts niet als enige vorm van verklaring van de betrouwbaarheid van de hosts zelf moet worden beschouwd, omdat het NTLM-verificatieprotocol niet kan garanderen dat u verbinding maakt met de host waarmee u verbinding wilt maken. In plaats daarvan moet u de instelling TrustedHosts beschouwen als de lijst met hosts waarvoor u de fout wilt onderdrukken die wordt gegenereerd door de identiteit van de server niet te verifiëren.

Doorlopende communicatie

Zodra de initiële verificatie is voltooid, versleutelt WinRM de lopende communicatie. Wanneer u verbinding maakt via HTTPS, wordt het TLS-protocol gebruikt om te onderhandelen over de versleuteling die wordt gebruikt voor het transport van gegevens. Wanneer u verbinding maakt via HTTP, wordt versleuteling op berichtniveau bepaald door het initiële verificatieprotocol dat wordt gebruikt.

  • Basisverificatie biedt geen versleuteling.
  • NTLM-verificatie maakt gebruik van een RC4-codering met een 128-bits sleutel.
  • Kerberos-verificatieversleuteling wordt bepaald door het etype in het TGS-ticket. Dit is AES-256 op moderne systemen.
  • CredSSP-versleuteling maakt gebruik van de TLS-coderingssuite die in de handshake is onderhandeld.

De tweede hop maken

Externe communicatie van PowerShell maakt standaard gebruik van Kerberos (indien beschikbaar) of NTLM voor verificatie. Beide protocollen worden geverifieerd bij de externe computer zonder referenties naar de computer te verzenden. Dit is de veiligste manier om te verifiëren, maar omdat de externe computer geen referenties van de gebruiker heeft, heeft deze geen toegang tot andere computers en services namens de gebruiker. Dit staat bekend als het 'tweede hopprobleem'.

Er zijn verschillende manieren om dit probleem te voorkomen. Zie Voor beschrijvingen van deze methoden en de voor- en nadelen van elke methode de tweede hop maken in Externe communicatie in PowerShell.

Verwijzingen