Signer skript og forsterk ExecutionPolicy med AppLocker og WDAC

I mange forretningsmiljøer er den raske løsningen fortsatt det foretrukne alternativet: senke forsvaret til PowerShell sette ExecutionPolicy til Ubegrenset Og det er det. Det fungerer, ja, men det åpner døren på vid gap for at enhver bruker kan kjøre potensielt farlige skript, både på servere og brukerdatamaskiner.

Realiteten er den Windows Det gir oss svært kraftige verktøy for å gjøre ting riktig: Signer skript, forsterk utførelsespolicyer og kompletter det med AppLocker eller WDAC å kontrollere hvilken kode som kjører på maskinene. Riktig konfigurert kan du ha automatisering, fleksibilitet og sikkerhet samtidig, uten å ty til råstyrke.

AppLocker og WDAC: kontrollere hvilke skript som kjører

AppLocker og dens utvikling, Windows Defender Programkontroll (WDAC), tillat definer hvilke skript og binærfiler som er autorisert til å kjøre i systemene dine. De erstatter ikke PowerShells ExecutionPolicy, men utfyller den heller som et ekstra lag med forsvar.

AppLocker fungerer med separate regelsamlinger (kjørbare filer, installasjonsprogrammer, skript, pakkede applikasjoner osv.), og i det spesifikke tilfellet med skript kontrollerer den bare noen få svært spesifikke filtyper. Dette er viktig fordi mange organisasjoner tror de "blokkerer alt" når de i virkeligheten bare filtrerer noen få formater.

I samlingen av skriptregler vurderer AppLocker bare følgende filformater:

• . Ps1 – PowerShell-skript
• BAT – klassiske batchfiler cmd
• . Cmd – en annen variant av batch-skript
• VBS – VBScript-skript
• . Js – JScript-skript

Når du aktiverer AppLocker for skript, og du ikke oppretter noen "Tillat"-regler, er standardvirkemåten veldig tydelig: Alt er blokkert bortsett fra det som er eksplisitt tillatt i reglene.Derfor er det så viktig å forstå de forhåndsbestemte reglene.

I en typisk policy tilbyr AppLocker en rekke standardregler for skriptsamlingen som vanligvis brukes som base:

• Tillat lokale administratorer å kjøre alle skript
  Regel (standard): «Alle skript»
  Bruker: INNEBYGD\Administratorer
  Rutetilstand: *\ (tilsvarende enhver rute)
• Tillat alle brukere å kjøre skript som ligger i Windows-mappen
  Regel (standard): «Alle skript som ligger i Windows-mappen»
  Bruker: Alle
  Rute: %windir%\*
• Tillat alle brukere å kjøre skript fra Programfiler-mappen
  Regel (standard): «Alle skript som ligger i Programfiler-mappen»
  Bruker: Alle
  Rute: %programfiles%\*

Med dette minimale settet oppnår du det operativsystemet og installerte applikasjoner fungerer uten å bryte sammenMen du hindrer brukere i å starte skript fra vilkårlige steder som skrivebordet eller mappen Nedlastinger.

Opprette AppLocker-regler ved hjelp av GPO

I domenemiljøer er det vanlig å Administrer AppLocker gjennom gruppepolicyerDette lar deg bruke den samme skriptkjøringskontrollen på hundrevis eller tusenvis av datamaskiner uten å måtte berøre hver enkelt.

For å konfigurere AppLocker, jobber du fra Gruppepolicyadministrator på en domenekontroller eller en RSAT-konsoll. AppLocker-konfigurasjonsbanen er:

Rute: Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas de control de aplicaciones → AppLocker

Innenfor AppLocker finner du flere grener: kjørbare filer, installasjonsprogrammer, skript og pakkede applikasjoner. For å styrke bruken av skript må du fokusere på samling av skriptregler og aktiver bruken av regler ved å klikke på «Konfigurer bruken av regler».

Når AppLocker er aktivert, oppfører den seg i henhold til hvitelistelogikk: Blokker som standard og tillat bare det som er definert.For å få fart på den første oppgaven kan du bruke Veiviseren «Generer regler automatisk», som analyserer en mappe og oppretter tillatelsesregler basert på:

• editoridentifiserer skript signert av en bestemt utgiver (veldig nyttig for bedriftsprogramvare eller programvare fra pålitelige leverandører).
• rutetillater eller blokkerer skript i bestemte stier (for eksempel C:\ScriptsSeguros\*).
• Fil-hash: den er basert på filens fingeravtrykk, så hvis filen endres, er ikke regelen lenger gyldig.

Denne automatiske genereringen sparer mye tid fordi Opprett tillatelsesregler for programvaren som allerede er installertDette reduserer risikoen for at systemer blir ubrukelige når AppLocker er aktivert. Du kan deretter supplere dette med manuelle regler for sensitive stier eller bedriftsskript.

WDAC: Forbedret versjon av applikasjonskontroll

Windows Defender Application Control (WDAC) er, for å si det enkelt, den «superladede AppLocker» for strengere eller moderne scenarierDen er designet for miljøer der du virkelig ønsker å ha en seriøs hvitlistingsmodell på binærnivå. drivere og manus.

WDACs logikk er lik: Du kan bare utføre det en policy eksplisitt tillater.Dette inkluderer EXE-er, DLL-er, PowerShell-skript, MSI-er, drivere, UWP-apper osv. Det er mye mer detaljert og kraftig enn AppLocker, men også mer komplekst å distribuere.

Mange administratorer kombinerer WDAC med PowerShell-kjøringspolicyer og skriptsignering for å bygge en lagdelt forsvarsmodell: el script Det må være tillatt av WDAC/AppLocker og også være i samsvar med ExecutionPolicy.Hvis en av disse feiler, vil den ikke kjøre.

PowerShell-kjøringspolicyer: hva de er og hva de ikke er

PowerShells ExecutionPolicies forårsaker mye forvirring fordi mange tror de er en slags «ugjennomtrengelig sikkerhetsmur»Faktisk gjør den offisielle dokumentasjonen det klart: de er en lett sikkerhetsmekanisme designet for å forhindre menneskelige feil og utilsiktet utførelse, ikke et anti-malware-system.

Implementeringspolitikken bestemmer, i korte trekk, Under hvilke forhold kan PowerShell laste inn skript og konfigurasjonsfiler?Før en .ps1 kjøres, sjekker PowerShell den gjeldende policyen og filens opprinnelse (lokal, ekstern, nedlastet fra Internett osv.), og bestemmer om den skal tillates, blokkeres eller vise advarsler.

Noen reelle fordeler med implementeringspolitikk er:

• De reduserer sannsynligheten for at en bruker utilsiktet kjører et ondsinnet skript mottatt via e-post eller lastet ned fra nettet.
• De fremmer tryggere skriptpraksiser, som for eksempel digital signatur med sertifikater i AllSigned- eller RemoteSigned-policyer.
• De tillater at forskjellige regler brukes avhengig av skriptets opprinnelse (lokal vs. ekstern), noe som gjør sikkerheten mer fleksibel.
• De kan kombineres med GPO, AppLocker og WDAC for å opprette en konsistent kodekontrollpolicy.

Men det er også viktig å være tydelige på deres begrensninger:

• De er enkle å omgå for en privilegert bruker, for eksempel ved å starte powershell.exe -ExecutionPolicy Bypass eller ved bruk av andre skriptspråk.
• De analyserer ikke innholdet i manuset: Et signert skript kan være skadelig hvis sertifikatet har blitt kompromittert eller forfatteren er ondsinnet.
• De påvirker bare PowerShell, ikke VBScript, Pythoninnebygde binærfiler osv., slik at de ikke erstatter en global applikasjonskontroll.
• En altfor slapp konfigurasjon («Ubegrenset» som standard) skaper en falsk følelse av sikkerhet, fordi det ser ut til at «det finnes en policy», men i praksis blokkerer den ikke noe relevant.

Typer av ExecutionPolicy i PowerShell

PowerShell definerer flere utførelsespolicymoduser som bestemmer hvilke skript som kan kjøres og hvorfraDet er viktig å forstå hver enkelt godt for ikke å overdrive eller komme til kort.

Hovedtyper av utførelsespolicy er:

begrenset

Dette er standardpolicyen på mange Windows-klienter, og det betyr at PowerShell-skript kan ikke kjøres i det hele tattKun følgende er tillatt kommandoer lagt inn interaktivt i konsollen eller ISE.

Denne policyen er egnet for arbeidsstasjoner eller servere der automatisering ikke forventesMen så snart du trenger å planlegge oppgaver eller distribusjoner med skript, må du endre det eller bruke en annen policy gjennom GPO.

Fjernsignert

Dette er standardpolicyen på mange Windows-servere. I denne modusen, Lokalt opprettede skript kan kjøres uten signaturImidlertid må ethvert skript som lastes ned fra Internett eller mottas fra en annen maskin signeres av en pålitelig utgiver.

Dette støttes av mekanismen til Merke av nettet (MotW)som merker nedlastede filer med regioninformasjon. Hvis du laster ned en .ps1-fil fra internett og vil kjøre den usignert, må du eksplisitt låse den opp med Unblock-File eller fjern den markeringen.

Allsignert

Med denne politikken, Alle skript og konfigurasjonsfiler, inkludert de som opprettes lokalt, må signeres digitalt. av et sertifikat som systemet stoler på. Hvis et av disse ikke er klarert eller signaturen er ugyldig, vil den ikke kjøre.

I tillegg vises vanligvis en advarsel første gang du kjører et skript signert av en ny utgiver, slik at brukeren kan bestemme om de vil stole på sertifikatet eller ikke. Dette er den ideelle policyen for bedriftsmiljøer der PKI eksisterer og det er et reelt ønske om å kontrollere hvem som kan publisere skript.

Ubegrenset

Denne policyen lar deg utføre alle manus uten obligatoriske signaturerEksterne eller nedlastede skript kan vise en advarsel til brukeren før de kjører, men ingenting et raskt klikk ikke kan fikse.

Det er fristende å bruke denne policyen i utviklingsmiljøer eller i laboratorier fordi «alt fungerer første gang», men i produksjon er det en tikkende tidsbombe. Det bør unngås på fysiske arbeidsstasjoner og servere.bortsett fra i svært berettigede tilfeller.

bypass

I Bypass, PowerShell ingen restriksjoner gjelder, og ingen advarsler visesDet er som om det ikke fantes noen ExecutionPolicy, primært utviklet for automatiseringsprosesser, orkestratorer, integrasjoner med andre applikasjoner eller CI/CD-pipelines der et annet sikkerhetslag allerede finnes.

Å bruke Bypass som en global policy på brukerutstyr er i bunn og grunn gi avkall på enhver form for beskyttelse mot skriptHvis det brukes, bør det være på en kontrollert måte, begrenset til bestemte økter eller svært spesifikke prosesser.

Udefinert og standard

Alternativet Udefinert indikerer at Det er ingen eksplisitt policy konfigurert i det omfanget. Hvis alle omfang er satt til Udefinert, vil standardvirkemåten være Begrenset på Windows-klienter og Eksternt signert på servere.

Standardalternativet brukes vanligvis til å gå tilbake til produktets standardinnstilling på det spesifikke systemet, det vil si Begrenset for klient og ekstern signering for server.

Omfang og prioritet for utførelsespolicy

Den samme maskinen kan ha flere utførelsespolicyer definert samtidighver i et annet område. PowerShell bestemmer hvilken som er effektiv basert på et prioritetshierarki.

De viktigste omfangene er:

• MaskinpolicyDet er definert av GPO på datamaskinnivå; det gjelder for alle brukere av maskinen.
• Brukerpolicyogså via GPO, men det påvirker bare den spesifikke brukeren som policyen gjelder for.
• ProsessDen gjelder bare for den gjeldende PowerShell-økten og ligger i minnet. Når du lukker konsollen, forsvinner den.
• Lokalmaskinpåvirker alle brukere av datamaskinen og lagres vanligvis i registeret (HKLM).
• Nåværende brukergjelder kun for gjeldende bruker (HKCU).

La prioritet mellom områder Dette er viktig, fordi det forklarer hvorfor endringene dine med Set-ExecutionPolicy noen ganger "ikke gjør noe":

1. MachinePolicy (GPO-teamet)
2. Brukerpolicy (GPO-bruker)
3. Prosess
4. Lokalmaskin
5. Nåværende bruker

Dette betyr det En policy definert via GPO vil alltid overstyre eventuelle lokale endringer du prøver å gjøre.Hvis MachinePolicy sier AllSigned og du prøver å sette RemoteSigned til LocalMachine, vil systemet fortsatt bruke AllSigned.

Slik viser og endrer du ExecutionPolicy

For å sjekke hvilken policy som faktisk er aktiv, anbefales det å gjennomgå alle retningslinjer etter område løping:

Get-ExecutionPolicy -List

Denne kommandoen viser deg, ovenfra og ned, policyene i MachinePolicy, UserPolicy, Process, CurrentUser og LocalMachine, og hvilken som er gyldig. grunnleggende diagnostisk verktøy når «noe ikke stemmer».

For å endre politikk på et bestemt område, bruker man Set-ExecutionPolicyNoen typiske eksempler:

• Angi AllSigned på teamnivå:
  Set-ExecutionPolicy AllSigned -Scope LocalMachine -Force
• Tillat lokale skript, men krev at eksterne skript signeres av gjeldende bruker:
  Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
• Endre bare gjeldende økt (nyttig for testing):
  Set-ExecutionPolicy Bypass -Scope Process -Force

For å endre policyen i LocalMachine-omfanget, Du må åpne PowerShell som administratorHvis et GPO definerer MachinePolicy eller UserPolicy, vil ethvert forsøk på å gjøre lokale endringer i lavere omfang returnere en feil som indikerer at Policyen styres av et gruppepolicyobjekt.

Bruk av GPO for å håndheve utførelsespolicyen

I bedriftsnettverk er det vanlig praksis å sentralisere disse konfigurasjonene ved hjelp av gruppepolicyobjekter (GPO-er). Dette gjøres ved hjelp av den relevante policyen. "Slå på skriptkjøring", tilgjengelig i:

Rute: Configuración del equipo → Plantillas administrativas → Componentes de Windows → Windows PowerShell

Denne konfigurasjonen tillater:

• Deaktiver skriptkjøring fullstendig (tilsvarende Begrenset).
• Aktiver skriptkjøring og velg policytypen (for eksempel RemoteSigned eller AllSigned).
• Ikke konfigurer den, i så fall vil PowerShell bruke lokale policyer (Set-ExecutionPolicy) uten at GPO-en forstyrrer.

Når GPO-en er koblet til ønsket OU, kan du tvinge applikasjonen sin på klienter med gpupdate /force og verifiser resultatet med Get-ExecutionPolicy -ListDu vil se hvordan MachinePolicy- eller UserPolicy-verdiene tar kontroll.

Signering av PowerShell-skript: den profesjonelle tilnærmingen

I stedet for å velge den enkle utveien ved å senke sikkerheten, er det rimelige for en organisasjon å gjøre La ExecutionPolicy være satt til AllSigned eller RemoteSigned og signer alle skript som skal sirkulere gjennom domenet.

Til dette trenger du en kodesigneringssertifikatDet finnes to alternativer: bruk en bedrifts-PKI (som ADCS) eller generer et selvsignert sertifikat for testformål. I et seriøst domenemiljø er den beste tilnærmingen å distribuere en intern CA og opprette en spesifikk mal for kodesignering.

Den typiske flyten med ADCS er:

• Installer Active Directory Certificate Services-rollen på en server.
• Opprett eller juster en Mal for kodesigneringssertifikat, som definerer hvilke brukere eller grupper som kan be om det (for eksempel administratorer eller DevOps-teamet).
• Publiser malen slik at den er tilgjengelig i CA-en.
• Fra administratorens datamaskin åpner du sertifikattillegget for den gjeldende brukeren (personlig butikk) og be om et nytt kodesigneringssertifikat til CA.
• Distribuer rotsertifikatet og, hvis aktuelt, mellomliggende sertifikater til alle datamaskiner som bruker GPO, slik at utstederen er klarert i hele domenet.

Når du har fått sertifikatet, kan du finne det i brukerens butikk med:

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

Med det sertifiserte objektet i hånden, Å signere et manus er så enkelt som:

Set-AuthenticodeSignature -FilePath C:\Scripts\MiScript.ps1 -Certificate $cert

Hvis du i stedet for å bruke det lokale lageret har en .pfx eksportert (for eksempel for å signere fra en byggemaskin), kan du laste inn med:

$cert = Get-PfxCertificate -FilePath C:\Certs\MiFirma.pfx
Set-AuthenticodeSignature -FilePath C:\Scripts\MiScript.ps1 -Certificate $cert

Det anbefales på det sterkeste for et bedriftsmiljø. Inkluder hele sertifiseringskjeden og en tidsstemplingsinstansslik at signaturen forblir gyldig selv om sertifikatet utløper:

Set-AuthenticodeSignature -FilePath C:\Scripts\MiScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer "http://timestamp.globalsign.com/scripts/timstamp.dll"

Når som helst du kan sjekk signaturstatusen fra et skript med:

Get-AuthenticodeSignature .\MiScript.ps1 | Format-List *

Hvis du trenger å kjøre raske tester uten en ekte PKI, lar PowerShell deg det opprett et selvsignert kodesigneringssertifikat:

New-SelfSignedCertificate -FriendlyName "Ejemplo firma de código" -CertStoreLocation Cert:\CurrentUser\My -Subject "CN=FirmaScripts" -Type CodeSigningCert

Omgåelse og andre metoder for å omgå ExecutionPolicy

For å unngå misforståelser er det verdt å huske på at Håndhevingspolitikken kan omgås på flere måter. Derfor bør det ikke være ditt eneste forsvarstiltak, men snarere et supplement til AppLocker/WDAC, NTFS-tillatelser og endepunktkontroller.

Det vanligste tilfellet er et system i Restricted eller AllSigned der du av en eller annen grunn må kjøre et spesifikt usignert skript. Hvis du har tilstrekkelige tillatelser, du kan bruke:

powershell.exe -ExecutionPolicy Bypass -File .\MiScript.ps1

eller kort sagt:

powershell -ep Bypass .\MiScript.ps1

Dette starter en ny instans av PowerShell bare for den utførelsen Med Bypass-policyen, uten å røre den globale konfigurasjonen. Det er praktisk, men også et perfekt eksempel på hvorfor ExecutionPolicies, alene, ikke stopper en angriper med interaktiv tilgang.

Det finnes også en spesiell miljøvariabel, $konvolutt:PSExecutionPolicyPreference, som tillater midlertidig overskriving av policyen i gjeldende økt:

$env:PSExecutionPolicyPreference = "Bypass"

Så lenge variabelen er satt, vil PowerShell bruke den verdien. Du kan sjekke det. med:

$env:PSExecutionPolicyPreference

Og når du vil gå tilbake til normal oppførsel, fjerner du ganske enkelt variabelen:

Remove-Item Env:PSExecutionPolicyPreference

Administrere upålitelige og blokkerte skript

Når du laster ned et skript fra Internett, markerer Windows det vanligvis med Mark of the WebDette fører til at visse policyer (som RemoteSigned) behandler det som et eksternt skript selv om det er på den lokale disken. Det typiske symptomet er feilmeldingen «Skriptkjøring er deaktivert» eller «Filen er ikke digitalt signert».

Hvis du har lest innholdet og stoler på det, kan du låse opp filen uten å endre ExecutionPolicy ved hjelp av:

Unblock-File -Path C:\Temp\ScriptDescargado.ps1

en gang låst oppOg avhengig av policyen din (for eksempel RemoteSigned), kan skriptet kjøre hvis det oppfyller de andre kravene. Dette er en mer raffinert arbeidsmåte enn å senke policyen til Ubegrenset.

I miljøer der AllSigned eller RemoteSigned kun brukes, må administrasjonen av Tillitssertifikater for eksterne utgivere Dette er også viktig. Hvis du laster ned et skript signert av en leverandør, må du bestemme om du vil importere sertifikatet deres som en klarert utgiver til riktig butikk, eller om du foretrekker å signere skriptet på nytt med ditt eget interne sertifikat.

NTFS-tillatelser og gruppepolicy som forsterkning

I tillegg til AppLocker, WDAC og ExecutionPolicy, ikke glem det grunnleggende: NTFS-tillatelser på katalogene der skriptene liggerSelv om en bruker kan kjøre en .ps1-fil, skal de ikke kunne endre kritiske skript som kjører med høye rettigheter.

Noen gode fremgangsmåter er:

• Lagre produksjonsskript på steder der bare administratorer eller en gruppe operatører har skrivetillatelser.
• Gi sluttbrukere kun lese- og kjøretillatelser når det er absolutt nødvendig.
• Hindre kritiske oppgaver i å hente skript som ligger i manipulerbare baner, for eksempel skrivebord, nedlastinger eller brukerprofiler.

Disse restriksjonene kan forsterkes med GPO-er som definerer tilgangskontrollister på bestemte mappersamt AppLocker-policyer som bare tillater at skript kjøres fra kontrollerte stier og, hvis mulig, signeres av bedriftens CA.

Ved å kombinere alt dette får du et scenario der Det er ikke nok å ha en skadelig .ps1-fil.Filen må være i en tillatt bane, overholde ExecutionPolicy, bestå AppLocker/WDAC, og angriperen trenger også tilstrekkelige tillatelser til å plassere eller endre den.

Arbeid med denne lagdelte tilnærmingen – skriptsignering, forbedret ExecutionPolicy, gjennomtenkt AppLocker/WDAC, korrekte NTFS-tillatelser og noe brukeropplæring – det er fullt mulig å ha intensiv automatisering med PowerShell uten å gjøre miljøet til skriptingens ville vesten.