Gennemse sikkerhedsfunktionen i Windows PowerShell
Som standard tillader de slutpunkter, som Windows PowerShell opretter, kun forbindelser for medlemmer af en bestemt gruppe. Fra og med Windows Server 2016 og Windows 10 omfatter disse grupper gruppen Brugere af fjernadministration og den lokale administratorgruppe. I et AD DS-domæne (Active Directory Domain Services) omfatter sidstnævnte også medlemmer af den globale domænegruppe Domæneadministratorer, da denne gruppe er medlem af den lokale administratorgruppe på alle domænetilsluttede computere. Før Windows Server 2016 og Windows 10 fik kun medlemmer af den lokale administratorgruppe som standard tilladelse til at bruge PowerShell-remoting. Det er dog muligt at ændre standarderne. Hvert slutpunkt har en SACL-liste (System Access Control List), som du kan ændre for at styre nøjagtigt, hvem der kan oprette forbindelse til det.
PowerShell Remoting og WinRM lytter på følgende porte:
- HTTP: 5985
- HTTPS: 5986
Standardfunktionsmåden for anmodning er at delegere dine logonoplysninger til fjerncomputeren, selvom du har mulighed for at angive alternative legitimationsoplysninger, når du opretter forbindelse. Den fjerncomputer, du opretter forbindelse til, bruger disse legitimationsoplysninger til at repræsentere dig og udføre de opgaver, du har angivet, ved hjælp af disse legitimationsoplysninger. Hvis du har aktiveret overvågning, overvåges de opgaver, som PowerShell sender på dine vegne, ud over de opgaver, du udfører. Det betyder, at remoting er sikkerhedsgennemsigtig og ikke ændrer dit miljøs eksisterende sikkerhed. Med fjernadgang kan du udføre alle de samme opgaver, som du ville udføre, mens du fysisk er placeret foran den lokale computer.
Seddel
På private netværk er standardreglen for Windows Firewall til PowerShell Remoting at acceptere alle forbindelser. På offentlige netværk tillader Windows Firewall-standardreglen kun PowerShell Remoting-forbindelser fra det samme undernet. Du skal eksplicit ændre denne regel for at åbne PowerShell Remoting til alle forbindelser på et offentligt netværk.
Sikkerhedsrisici og gensidig godkendelse
Delegering af dine legitimationsoplysninger til en fjerncomputer indebærer nogle sikkerhedsrisici. Hvis en hacker f.eks. repræsenterer en kendt fjerncomputer, kan du potentielt overføre meget privilegerede legitimationsoplysninger til denne hacker, som derefter kan bruge dem til skadelige formål. På grund af denne risiko kræver remoting som standard gensidig godkendelse, hvilket betyder, at du skal godkende dig selv på fjerncomputeren, og fjerncomputeren skal også godkende sig selv over for dig. Denne gensidige godkendelse garanterer, at du kun opretter forbindelse til præcis den computer, du havde tiltænkt.
Gensidig godkendelse er en oprindelig funktion i Active Directory Kerberos-godkendelsesprotokollen. Når du opretter forbindelse mellem domænecomputere, der er tillid til, sker der automatisk gensidig godkendelse. Når du opretter forbindelse til computere, der ikke er domæneforbundne, skal du angive en anden form for gensidig godkendelse i form af et SSL-certifikat og DEN HTTPS-protokol, der skal konfigureres på forhånd. En anden mulighed er at deaktivere kravet om gensidig godkendelse ved at føje fjerncomputeren til din lokale TrustedHosts-liste. Bemærk dog, at TrustedHosts bruger NTLM-godkendelse (Windows NT LAN Manager), som ikke sikrer serveridentitet. Som med enhver protokol, der bruger NTLM til godkendelse, kan hackere, der har adgang til en domænetilsluttet computers konto, få domænecontrolleren til at oprette en NTLM-sessionsnøgle og dermed repræsentere serveren.
Seddel
NTLM-godkendelsesprotokollen kan ikke sikre destinationsserverens identitet. den kan kun sikre, at den allerede kender din adgangskode. Derfor skal du konfigurere destinationsservere til at bruge SSL til PowerShell Remoting. Hvis du henter et SSL-certifikat, der er udstedt af et nøglecenter, der er tillid til, og som klienten har tillid til, og tildeler det til destinationsserveren, forbedres sikkerheden for den NTLM-baserede godkendelse, hvilket hjælper med at validere både bruger-id'et og serveridentiteten.
Overvejelser i forbindelse med computernavn
Hvis AD DS-baseret godkendelse skal fungere, skal PowerShell-remoting kunne søge efter og hente AD DS-computerobjekter (Active Directory Domain Services). Det betyder, at du skal referere til destinationscomputere ved hjælp af deres fuldt kvalificerede domænenavne (FQDN). IP-adresser eller DNS-aliasser (Domain Name System) fungerer f.eks. ikke, fordi de ikke leverer remoting med den gensidige godkendelse, den har brug for. Hvis du skal referere til en computer med en IP-adresse eller et DNS-alias, skal du oprette forbindelse ved hjælp af HTTPS, hvilket betyder, at fjerncomputeren skal være konfigureret til at acceptere protokollen. Du skal også føje IP-adressen eller DNS-aliasset til din lokale TrustedHosts-liste.
Seddel
Der er en særlig undtagelse for computernavnet localhost, som gør det muligt for dig at bruge det til at oprette forbindelse til den lokale computer uden andre konfigurationsændringer. Hvis den lokale computer bruger et klientbaseret operativsystem, skal WinRM konfigureres på det.
Listen TrustedHosts
Listen TrustedHosts er en lokalt konfigureret indstilling, som du også kan konfigurere ved hjælp af et gruppepolitikobjekt. Listen TrustedHosts optæller de computere, hvor gensidig godkendelse ikke er mulig. Computere skal angives med det samme navn, som du skal bruge til at oprette forbindelse til dem, uanset om det er det faktiske computernavn, et DNS-alias eller en IP-adresse. Du kan bruge jokertegn til at angive SRV*, som gør det muligt for alle computere, hvis navn eller DNS-alias starter med SRV at oprette forbindelse. Vær dog forsigtig med denne liste. Selvom listen TrustedHosts gør det nemmere at oprette forbindelse til computere, der ikke er domænecomputere, uden at skulle konfigurere HTTPS, tilsidesætter den en vigtig sikkerhedsforanstaltning. Det giver dig mulighed for at sende dine legitimationsoplysninger til en fjerncomputer uden at afgøre, om computeren faktisk er en, som du havde til hensigt at oprette forbindelse til. Du bør kun bruge listen TrustedHosts til at angive computere, som du ved ikke er kompromitteret, f.eks. servere, der er placeret i et beskyttet datacenter. Du kan også bruge TrustedHosts til midlertidigt at aktivere forbindelser til ikke-domænecomputere på et kontrolleret netværksundernet, f.eks. nye computere, der er i gang med en klargøringsproces.
Seddel
Som bedste praksis bør du undgå at bruge listen TrustedHosts, medmindre det er absolut nødvendigt. Konfiguration af en ikke-domænecomputer til at bruge HTTPS er en mere sikker langsigtet løsning.
Privatliv
Som standard bruger remoting HTTP, som ikke tilbyder beskyttelse af personlige oplysninger eller kryptering af indholdet af din kommunikation. Windows PowerShell kan dog som standard anvende kryptering på programniveau. Det betyder, at din kommunikation modtager en vis grad af beskyttelse af personlige oplysninger og beskyttelse. På interne netværk er denne kryptering på programniveau generelt tilstrækkelig til at opfylde organisationens sikkerhedskrav.
I et domænemiljø, der bruger Kerberos-standardgodkendelsesprotokollen, sendes legitimationsoplysninger i form af krypterede Kerberos-billetter, der ikke indeholder adgangskoder.
Når du opretter forbindelse ved hjælp af HTTPS, krypteres hele kanalen ved hjælp af krypteringsnøglerne for fjerncomputerens SSL-certifikat. Selvom du bruger basisgodkendelse, sendes adgangskoder derfor ikke i klartekst. Men når du opretter forbindelse ved hjælp af HTTP- og basisgodkendelse til en computer, der ikke er konfigureret til HTTPS, sendes legitimationsoplysninger (herunder adgangskoder) i klartekst. Dette kan f.eks. ske, når du opretter forbindelse til en ikke-domænecomputer, som du føjer til din lokale TrustedHosts-liste. Dette kan også ske, når du bruger en domænetilsluttet computer ved at angive dens IP-adresse i stedet for værtsnavnet.
Da legitimationsoplysninger overføres som klartekst i dette scenarie, skal du sikre dig, at du kun opretter forbindelse til en ikke-domænecomputer på et kontrolleret og beskyttet netværksundernet, f.eks. et, der specifikt er angivet til klargøring af en ny computer. Hvis du rutinemæssigt skal oprette forbindelse til en ikke-domænecomputer, skal du konfigurere den til at understøtte HTTPS.