Det er ikke enkelt å håndtere trusler mens du opprettholder funksjonalitet og forbedrer ytelsen og brukeropplevelsen i en VDI. Å holde det sikkert og herde serverne er avgjørende. Selv om det ikke er noen magisk kule, er det absolutt noen få enkle sikkerhetstiltak IT kan ta for å holde VDI i gang.
Forbereder seg på det verste: Det er uunngåelig at stasjonære datamaskiner og andre endepunktenheter i VDI kjeden blir brutt. Med usikrede Wi-Fi-nettverk, uherdede applikasjoner (tenk Zoom) og ren tekst-e-post som er sårbare for skannere overalt, har angripere et mål som er langt lettere å komme inn på enn en beskyttet desktopløsning, som sannsynligvis allerede er kompromittert eller har gapende sikkerhetshull.
Selv om et desktopbrudd oppdages, kan det være en tidkrevende prosess å finne ut hvordan det skjedde og omfanget av skaden som er gjort. Gjenoppretting og gjenoppretting av funksjonalitet avhenger av skalaen og kompleksiteten til infrastrukturen.
Å velge en pålitelig påloggingsmetode: Det er to alternativer for brukere å logge på VDI. Den ene er Single Sign-On (SSO), eller én pålogging for å få tilgang til alle ressurser. Selv om dette umiddelbart kan virke risikabelt (når en hacker har passordet, kan de få tilgang til alle brukerens privilegier), er fordelen at brukeren bare har ett passord å huske, og derfor sannsynligvis ikke vil skrive det ned noe sted. SSO er ideell når brukere må få tilgang til tjenester eller apper som bor utenfor skrivebordet deres, som SaaS.
Den andre er tofaktor autentisering, som krever flere påloggingsopplysninger og handlinger for å logge på – for eksempel et passord som legges inn på skrivebordet og et trykk på mobilskjermen, eller å logge på en VPN og deretter på en tjeneste levert av nettleseren. Naturligvis er dette sikrere enn SSO.
Administrere brukeridentiteter: Dette er basert på Zero Trust-modellen, som fastsetter at brukere må gis tilgang til kun de ressursene de trenger for rollen eller oppgavene de er tildelt, og ingenting mer. Retningslinjer spesifiserer bruker- og grupperoller, og overvåker og kontrollerer aktive økter individuelt for alle påloggede brukere. Dette forhindrer en angriper fra å infiltrere en brukerøkt og få tilgang til sensitive data eller komme inn på serveren sideveis.
Applikasjonssegmentering: Applikasjoner kan presenteres på en slik måte at de er isolert og atskilt fra andre forretningskritiske eller sensitive applikasjoner i VDI. Granulære retningslinjer basert på prosesser, ressurser osv, går langt i å kutte sårbarheter. Ring-fencing-segmenter i VDI sikrer at angripere ikke kan oppnå eller utnytte ett brudd.
Kombinert med brukeridentitetsadministrasjon kan IT sørge for at alle brukere bare kan få tilgang til de tjenestene og delene av applikasjonen de trenger, og ikke flytter ut av det relevante miljøet.
Strenge retningslinjer for databeskyttelse: Moderne hackere er mer interessert i å stjele data og åndsverk enn å bryte seg inn på servere eller nettverk og gjøre skade. VDI-er gir mulighet for strengere datakontroll, og IT bør dra nytte av dette. Til å begynne med bør data aldri forlate datasenteret eller den sentrale serveren, verken lokalt eller i skyen. Datasenterressurser kan brukes til automatisk sikkerhetskopiering og gjenoppretting av skrivebordsdata. Alle data under overføring skal være kryptert.
Omfattende synlighet: Sikkerhetsløsningen eller VDI-administrasjonsplattformen skal tillate administratorer å overvåke i sanntid (på forespørsel) følgende parametere:
- alle nodene som er online
- om hvert skrivebord eller VM er oppdatert og patchet eller ikke
- hver bruker som er pålogget, sammen med aktivitetslogging
- prosessene og tjenestene som kjører på hver server og node
- hvilke applikasjoner og tjenester som brukes til hvilke formål, ved hvilke økter
- alle prosesser og endringer som genereres
- hvordan prosesser kommuniserer
Kontinuerlig, automatisert endepunktsikkerhetsadministrasjon: Det er avgjørende for IT å sikre at endepunktprogramvare og -maskinvare til enhver tid er i samsvar med sikkerhetspolicyene og -standardene til organisasjonen. En sikker VDI trenger automatiserte kontroller og tilnærminger til programvareinstallasjon og fjerning, patcher og oppgraderinger, avviksdeteksjon og støtteprosedyrer ved endepunktene. Vi har en kontinuerlig prosess med Baseline Security som utgjør grunnstammen av sikkerhetsinnstillinger. Men det bør settes en prosess for å se på de øvrige sikkerhetsinnstillingene for VDI miljøet.
Proaktiv hendelsesrespons: Det er en myte at virtuelle skrivebord er immune mot angrep og sikkerhetsbrudd. Riktignok har de mindre sårbarheter enn fysiske stasjonære datamaskiner, men de er fortsatt mottakelige for ulike typer keyloggere, skjermskrapere (skjermbilde overtagelse), ondsinnede e-postlenker, Remote Access Trojans (RAT).
Løsningen er derfor å ha en pragmatisk hendelsesresponsprosess som fremskynder trusselredusering og gjenoppretting, samtidig som driftsavbrudd minimeres. Så snart en infisert VM blir oppdaget, må den blokkeres og isoleres fra nettverket, eller til og med termineres om nødvendig, med fokus på å redde brukerdata.
Hvordan angripe VDI
La oss se på noen av angrepsvektorer som kan bli utnyttet.
- Nummer 1 av Application Jailbreak-metodene fra nesten alle applikasjoner. Når jeg kan skrive regedit, cmd, powershell, file:\\\c:\, er det da dårlige ting begynner å skje.
- Løsning: Policy: GPO: User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Remove Run
- Trenger brukerne virkelig tilgang til de lokale stasjonene på serveren og/eller skrivebordet? Dette kan forhindres ved å «skjul de angitte stasjonene i Min datamaskin» #Jailbreaking #Skattejakt
- Løsning: GPO: User Configuration/Administrative Templates/File Explorer/ Prevent Access to drives in My Computer
- Hjelp er en av de beste Application Jail break-metodene? Å begrense hva som kan startes fra Help er ditt beste forsvar. Hjelp->Om har ført meg til en nettleser, CMD, PS og PartyTime123.ps1
- Løsning: GPO: User Configuration\Policies\Administrative Templates\System\Restrict these applications from being launch from Help
- Exe for å blokkere fra hjelp: exe, cmd.exe, regedit.exe, mmc.exe, powershell.exe og hvilken som helst annen nettleser eller EXE noe i programmet prøver å starte.
- Trenger brukerne muligheten til å koble til nettverksstasjoner i løpet av en økt? De fleste er allerede tilrettelagt for brukeren, så det er ikke behov for dem å gjøre det på egen hånd.
- Løsning: GPO: User Configuration/Administrative Templates/File Explorer/Remove “Map Network Drive” and “Disconnect Network Drive”
- Brukere som ser og eller kan endre NTFS. En enkel «Fjern sikkerhet-fane» kan fikse det.
- Løsning: GPO:User Configuration/Administrative Templates/File Explorer/Remove Security tab
- Trenger brukerne komme til kontrollpanelet? I 99,9 % av løsninger er det et «NEI», og det betyr at «Forby tilgang til kontrollpanelet» er din beste venn. #HrmHvaKanJegGjøreHer?
- Løsning: GPO: User Configuration/Administrative Templates/Control Panel / Prohibit access to the Control Panel
- Jeg er ganske sikker på å åpne Registerredigering som bruker er dårlig, la oss låse det.
- Løsning: Hindre tilgang til registerredigeringsverktøy med en enkel policy
- Trenger vi at brukerne dine skal kjøre Server Manager eller PowerShell eller andre AdminTools? Det er en flott GPO som vil fikse opp filsystemrestriksjoner, og den skal blokkeres. Unntak kan gjøres med Gruppeinnstillinger.
- «Skjul nettverksplasseringsikon på skrivebordet» for å sikre at man ikke kan komme et sted de ikke burde som ikke har blitt sikret ennå.
- Løsning: GPO: User Configuration/Administrative Templates/File Explorer/No Entire Network in Network Locations.
- Løsning. GPO: User Configuration/Administrative Templates/Desktop/Hide Network Locations on Desktop
- Bør brukerne kunne komme til ledeteksten? De fleste burde ikke trenge tilgang til det. Mengden av rekognosering- og utførelsesmuligheter er nesten ubegrensede der.
- Brukere ligger som lokal admin på VDI. Veldig enkelt å utnytte.
HER ER ETT EKSEMPEL PÅ ETT ANGREP MAN KAN GJØRE
Hvis vi tar utgangspunkt i at følgende sikkerhetsinnstillinger er definert. Blir det straks litt vanskeligere å hente ut informasjon:
- Hviteliste over hvilke applikasjoner som kan kjøres i VDI.
- Bla mellom (sensitive) kataloger er ikke mulig gjennom utforskeren.
- Tilordning av lokal klientstasjon er deaktivert.
- Mapping av enheter (USB, seriell …) er deaktivert.
- Utklippstavlen deles ikke mellom klientmaskinen og VDI.
- Ingen -direkte- Internett-tilkobling fra det eksterne skrivebordet.
Oppsummert er kjøring av tredjepartsprogrammer forbudt, og det er heller ikke mulig å -direkte- overføre filer mellom verten og VDI. Det som imidlertid er tilgjengelig er en notisblokk og Excel.
Det er da mulig å samhandle med systemets APIer direkte fra VBA. Å kjøre kode gjennom VBA åpner for et bredt spekter av muligheter, men det kan bli noe nitidig å jobbe med å bygge makroer for hver funksjonalitet som ønskes. Det ideelle scenariet i ett angrep ville være å bruke en første makro for å injisere i selve excel-prosessen (eller en annen) en liten del av koden som er ansvarlig for å laste en DLL. Siden excel-prosessen er hvitlistet, og dermed kan den brukes som vert for ondsinnede formål.
Når det gjelder hva som skal inneholde DLL-en som skal lastes inn i prosessen, kan dette gjøres på to forskjellige måter. Det første alternativet er å bygge en cmd.dll ved å endre ReactOS cmd-koden litt. Dette er en enkel teknikk å implementere, siden den bare krever noen få minimumsendringer og kompilering for målplattformen. Det andre alternativet er å bygge en egen «cmd på steroider» ved å legge til kommandoer som automatiserer visse oppgaver (for eksempel sjekke mulige passord i SYSVOL, liste domeneinformasjon, etc.).
En av de to alternativene krever å løse et tidligere problem: overfør filen fra en lokal maskin til VDI. Det er ikke mulig å mappe en lokal stasjon, eller laste ned DLL fra Internett. Heller ikke utklippstavlen kan brukes som mellomledd. Hvilke andre alternativer er tilgjengelige?
Den eneste måten å overføre filene til VDI er ved å skrive dem, ett tegn om gangen, som base64 i notisblokken. Gjennom tastaturemulering, og ved å bruke base64 som koding, er det mulig å overføre innholdet i en fil som ligger på en lokal maskin til det eksterne skrivebordet. På denne måten unngås alle restriksjoner i miljøet.
Når filen er skrevet i ren tekst inne i notisblokken, er det som gjenstår å lagre den og dekode den for å få den originale DLL-filen. Dekodingsprosessen kan gjøres enten gjennom en VBA-makro (som skal overføres med samme metode) eller ved å dra nytte av certutil-verktøyet som er installert på alle Windows maskiner.
For emulering av tastetrykk er det mange verktøy tilgjengelig, som f.eks Pyautogui-library. En veldig abstrakt implementering av ideen er følgende:
- Åpne filen du vil overføre i binær modus.
- Kod informasjonen i base64.
- Skriv det forrige resultatet i VDI ved å bruke pyautogui-library som emulerer en «normal» interaksjon med tastaturet.
Med DLL på målsystemet kan den lastes inn og brukes til å fortsette med angrepet. På samme måte kan et hvilket som helst annet verktøy lastes ned til VDI ved å bruke denne metoden. Men på grunn av hvitelisten må de endre og kompilere dem som en DLL.
Selv om denne hindringen har blitt lett løst, er det fortsatt en annen hindring å overvinne. Hvordan eksfiltrere informasjon fra VDI til en lokal maskin?
Det samme problemet med hvordan «laster opp» filer på den eksterne maskinen, hvordan «pakker du ut» relevant informasjon eller fil? Og ikke bare det: utklippstavlen kan ikke brukes til å kopiere viktig informasjon. Anta at du vil eksportere noen XML-er som ligger i SYSVOL som inneholder nyttig legitimasjon for å utføre sideloading. Eller kanskje det er noen sertifikater som senere vil være nyttige for å koble til Wi-Fi-nettverket. Hvordan «eksporterer» du dem enkelt?
Metoden for å håndtere dette problemet er å bruke optisk tegngjenkjenning for å konvertere informasjonen som vises på det eksterne VDI-skrivebordet til tekst. Det er flere tilgjengelige alternativer som gjør det mulig å utføre denne operasjonen automatisk. Man kan for eksempel bruke Tesseract, siden det har en omfattende dokumentasjon og bindinger for forskjellige språk.
Metodikken for dette er ganske enkel. Et nytt vindu på notisblokken åpnes i fullskjerm, og innholdet som skal eksfiltreres limes inn i det (i tilfelle av binære data eller problematiske tegn for OCR, må det først kodes i base64). Et nøkkelord legges til for å gjøre dette lettere senere. Når dette trinnet er gjort, fortsetter vi å kjøre skriptet som utfører følgende handlinger:
- Ta et skjermbilde av det angitte området (posisjon X, Y og størrelse).
- Konverter skjermbildet til tekst.
- Sjekk om det endelige nøkkelordet er i teksten.
- Hvis nøkkelordet ikke er der, emuler «pagedown» og gå tilbake til punkt 1.
- Hvis nøkkelordet er der, fullfør.
Selv når en har utført ustrakt herding på et VDI-miljø, er det alltid en måte, ved hjelp av kreativitet, å omgå tiltakene som er tatt.
Hvordan beskytte VDI?
VDI er beskyttet i all hovedsak av følgende:
- Defender Security
- Baseline Security Policy
- Group Policyer
- Citrix Policy
- MFA, SSO og FAS
Citrix-policyer er ikke den kuleste tingen å rote med, men de er veldig viktige og blir veldig ofte oversett fra et sikkerhetsperspektiv.
Når en gjør Citrix Security Assessments er de svake policiene vanligvis det nest største funnet (etter patching) fordi de vanligvis bare er satt som standard og eller filtrene og eller rekkefølgen deres gjør dem svakere enn de fleste klienter forventer at de skal være med noen av disse faktorene.
Mange av disse innstillingene er aktivert som standard fordi det har vært behov for disse innstillingene, men hvis man bare ser på dem én gang til, bør man i de fleste tilfeller kunne deaktivere mange av dem.
- Copy\Paste
- Bi-directional
- Copy\Paste Write Allowed Formats – All
- Drive Mappings
- On by Default
- Major
- Client Fixed Drives
- Client Network Drives
- Client Removable Drives
- Minor
- Client Floppy Drives
- Client Optical Drives
- USB Mounts
- Disabled by Default
- Restrict the Devices
- Others
- Printer Mapping
- LPT Mapping
- COM Mapping
- Microphone Mapping
- Audio Mapping
- Major
- On by Default
Citrix Policy Security Severity Chart
| Risk | Setting | Default Setting |
| High | Copy\Paste | Allowed |
| High | Copy\Paste Write Allowed Formats | Blank |
| High | Client Fixed Drives | Allowed |
| High | Client Network Drives | Allowed |
| High | Client Removable Drives | Allowed |
| High\Medium | Client USB Mapping | Prohibited |
| High\Medium | Printer Mapping | Allowed |
| Medium\Low | Client Floppy Drives | Allowed |
| Medium\Low | Client Optical Drives | Allowed |
| Medium\Low | LPT Mapping | Prohibited |
| Medium\Low | COM Mapping | Prohibited |
| Medium\Low | Microphone Mapping | Allowed |
| Low | Audio Redirection | Allowed |
Alvorlighetsgraden til noen av disse elementene vil variere basert på innstillingen og om disse elementene er i bruk eller om de kan brukes på en måte som skader bedriften.
Citrix VDI miljøet har blitt migrert\oppgradert om og om igjen, og kan sannsynligvis ha et problem uten at vi vet om det.
1. Kopier og lim inn
I noen tilfeller er det faktisk nødvendig, men i de fleste tilfeller kan det deaktiveres eller stilles inn for retningsbestemmelse sammen med å begrense forskjellige lime inn forskjellige formater utover bare tekst.
Utklippstavle skrive tillatte formater
Blank som standard, noe som betyr at skjermbilder enkelt kan eksfiltreres hvis du gir noen en skrivebordsøkt eller tilgang til en applikasjon uten at kjøring forhindres fra mange Windows-undersystemer som kan dra nytte av dette.
Det anbefales sterkt å bare tillate CF_Text. Hvis Microsoft Suite må brukes utover bare tekst, legg til CFX_OfficeDrawingShape som det andre formatet.
Mange av disse andre metodene er måter som nyttelast kan sendes til serveren\skrivebordet eller data kan sendes ut enn bare tekst. Hvem ville ha gjettet at det var 23 ting å kopiere\lim inn?
CF_TEXT
CF_BITMAP
CF_METAFILEPICT
CF_SYLK
CF_DIF
CF_TIFF
CF_OEMTEXT
CF_DIB
CF_PALETTE
CF_PENDATA
CF_RIFF
CF_WAVE
CF_UNICODETEXT
CF_ENHMETAFILE
CF_HDROP
CF_LOCALE
CF_DIBV5
CF_OWNERDISPLAY
CF_DSPTEXT
CF_DSPBITMAP
CF_DSPMETAFILEPICT
CF_DSPENHMETAFILE
CF_HTML
CFX_RICHTEXT
CFX_OfficeDrawingShape
CFX_BIFF8
2. Drive Mappings
Dette er den absolutt beste måten for ansatte og/eller angripere å få ting inn og ut av miljøet. I de fleste tilfeller er det ikke nødvendig, men er aldri deaktivert.
Hvem har en diskett eller optisk stasjon lenger, kan vi i det minste slå av disse to?
Tenk på hvilke data brukeren har tilgang til på sine lokale datamaskiner, i mange tilfeller kan man eller kanskje ikke være i stand til å kontrollere disse endepunktene til tredjepartsenheter.
De fleste brukere vil ha noen tilkoblede stasjoner på klienten som vil bli koblet til som standard, og hvem vet om sikkerhetsteamet ønsket en Citrix-økt for å bygge bro over dette gapet fra en nettverksressurs til endepunktet.
Hvor mange SMB-shares har Everyone på Share-tillatelser sammen med de faktiske filtillatelsene?
Man kan bruke https://www.mcafee.com/us/downloads/free-tools/sharescan.aspx for å finne dem på nettverket, det er også mer avanserte måter, men dette er et av de enklere verktøyene å kjøre.
USB-
Den gode tingen er at denne innstillingen som standard forbyr disse tilordningene.
USB-stasjon er i de fleste tilfeller hovedkandidat nummer 2 etter e-post for dataeksfiltrering.
Det er mange måter som kartlegging av USB-enheter også kan introdusere ustabilitet sammen med andre mulige angrep, så filtrering av enheter hvis de må være aktivert er det sikreste alternativet.
Printer Mapping
Dette er aktivert som standard, og i mange tilfeller er dette nødvendig for at applikasjon X skal fungere og for at brukeren skal gjøre jobben sin. Program som ikke trenger å skrive ut, bør deaktiveres eller i det minste bare begrense det til bare programmene som trenger det og ekskluder det fra alt annet.
LPT-mapping
Mapping av disse gamle fysiske skriverporter er aktivert som standard, men jeg har ikke sett dem faktisk siden de fleste skrivere nå er nettverk baserte. Dette bør deaktiveres, og som alltid, hvis du ikke trenger det, deaktiver det.
COM-mapping
Dette er deaktivert som standard, så vanligvis finner jeg det ikke aktivert, men jeg ser det nå og da for noen medisinske enheter og i produksjon. Hvis det må aktiveres, filtrerer du det bare til serverne/desktops som trenger det.
Mikrofonmapping
Dette er flott for videokonferanser sammen med diktering, men i mange tilfeller er det kanskje ikke nødvendig og bør deaktiveres. Dette virker kanskje ikke særlig sikkerhetsrelatert å kunne spille inn stemmen i applikasjoner, men det er en måte data kan komme inn på.
Audio Mapping
Dette kan heller ikke virke som om det er veldig sikkerhetsrelatert element også, men i mange bransjer kan en lydstrøm være svært sensitive data. Hvis noen kan lytte til lyden og eller hvis du har tilordnede stasjoner aktivert, kan de trekke dataene ut.
Hvis man ikke trenger lyd vil jeg anbefale å slå den av.
Dette er den ønskelige sikkerhets policyen:
Hva kan vi gjøre for å heve sikkerheten ytterligere?
AppLocker
Programkontroll eller restriksjonspolicyer er en veldig kraftig sikkerhetskontrollløsning. Det er en veldig kraftig måte å gjøre ting på, men det er også den minst benyttede funksjonen fra det jeg har sett i alle PC- og VDI-distribusjonene jeg har jobbet med.
Med utgivelsen av Windows XP-utgivelsen i 2001 kom Software Restriction Policies først og deretter omdøpt til AppLocker da Windows 7 ble utgitt. Uten et begrensningssystem for applikasjonskjøring er du garantert i fare selv med en antivirusløsning installert. Når kjøring av applikasjoner er ubegrenset og phishing-e-post sendes med en ondsinnet eksekverbar kode, er det eneste håp at AV-løsning vet at den er dårlig og vil blokkere den. Forsvar i dybden er en grunnleggende sikkerhetsstrategi for å bruke løsninger i en lagdelt metodikk for å forsøke å sikre gapene mellom løsningene og gi en generelt sikrere distribusjon. Bruk av Application Control\Allowlisting er en nøkkelkomponent i enhver Windows-sikkerhetsstrategi.
Nå er det to hovedmåter man kan gjøre applikasjonsbegrensning og kontroll med Microsoft akkurat nå.
- AppLocker
- Windows Defender Application Control (WDAC)
