Beveiligingsoverwegingen voor externe communicatie met PowerShell met WinRM
Externe communicatie van PowerShell is de aanbevolen manier om Windows-systemen te beheren. Externe communicatie van PowerShell is standaard ingeschakeld in Windows Server 2012 R2. 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), de Microsoft-implementatie van het WS-Management-protocol (Web Services for Management), zodat gebruikers PowerShell-opdrachten kunnen uitvoeren op externe computers. Meer informatie over het gebruik van externe PowerShell-opdrachten vindt u bij het uitvoeren van externe opdrachten.
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 toegang van PowerShell
Externe communicatie van PowerShell (en WinRM) luistert op de volgende poorten:
- HTTP: 5985
- HTTPS: 5986
Externe communicatie via PowerShell staat standaard alleen verbindingen toe van leden van de groep Administrators. Sessies worden gestart in de context van de gebruiker, zodat alle besturingselementen voor toegang van besturingssystemen die worden toegepast op afzonderlijke gebruikers en groepen, blijven van toepassing terwijl ze zijn verbonden via externe communicatie via PowerShell.
In privénetwerken accepteert de standaardregel voor Externe communicatie van 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 via PowerShell maakt gebruik van WinRM voor communicatie tussen computers. WinRM wordt uitgevoerd als een service onder het netwerkserviceaccount en spawn geïsoleerde processen die worden uitgevoerd als gebruikersaccounts voor het hosten van PowerShell-exemplaren. Een exemplaar van PowerShell dat wordt uitgevoerd als één gebruiker heeft geen toegang tot een proces waarop een exemplaar van PowerShell wordt uitgevoerd als een andere gebruiker.
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 PowerShell-verbinding: 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 een soort delegeerbare referentie te verzenden. Om de gebruikersidentiteit te bewijzen, vereist het NTLM-protocol dat zowel de client als de server een sessiesleutel uit het wachtwoord van de gebruiker berekent zonder het wachtwoord zelf uit te wisselen. De server kent meestal niet het wachtwoord van de gebruiker, 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
Aangezien het NTLM-verificatieprotocol de identiteit van de doelserver niet kan garanderen (alleen dat het al uw wachtwoord kent), kunt u doelservers configureren voor het gebruik van SSL voor externe communicatie met PowerShell. Door een SSL-certificaat toe te wijzen 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.
Fouten met serveridentiteit op basis van NTLM negeren
Als het implementeren van een SSL-certificaat op een server voor NTLM-verbindingen onhaalbaar is, kunt u de resulterende identiteitsfouten onderdrukken door de server toe te voegen aan de lijst met Vertrouwde WinRM-adressen . Houd er rekening mee dat het toevoegen van een servernaam aan de Lijst TrustedHosts niet mag worden beschouwd als een vorm van verklaring van de betrouwbaarheid van de hosts zelf, omdat het NTLM-verificatieprotocol niet kan garanderen dat u in feite 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 kunnen 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 om gegevens te transporteren. 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
etypein 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 via PowerShell maakt standaard gebruik van Kerberos (indien beschikbaar) of NTLM voor verificatie. Beide protocollen verifiëren zich 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 niet beschikt over de referenties van de gebruiker, 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 elk van deze methoden de tweede hop maken in Externe communicatie van PowerShell.