Categorie: Citrix

Citrix ADC kwetsbaarheid

Enkele dagen geleden heeft Citrix melding gemaakt van een kwetsbaarheid in hun Citrix ADC platform. Het betreft een zogenaamde ‘Oracle Padding vulnerability’ waarmee een potentiele aanvaller mogelijk het TLS verkeer van de ADC’s kan onderscheppen en ontsleutelen waardoor deze informatie leesbaar gemaakt wordt. Voor de kwetsbaarheid is een CVE kwetsbaarheidsrapport opgesteld onder nummer CVE-2019-6485.

Binnen enkele dagen zullen de details onder meer in de National Vulnerability’ Database (NVD) van de National Institute of Standards and Technology (NIST) gepubliceerd worden op https://nvd.nist.gov/vuln/

Getroffen versies

Citrix maakt in het https://support.citrix.com/article/CTX240139 artikel kenbaar dat enkel de Netscaler ADC’s die gebruik maken van hardware acceleratie getroffen zijn door de bovengenoemde kwetsbaarheid. Hierdoor zijn de Virtual Appliances (de VPX) varianten van de ADC’s niet kwetsbaar evenals de onderstaande modellen:

• MPX 5900 series
• MPX/SDX 8900 series
• MPX/SDX 15000-50G
• MPX/SDX 26000-50S series
• MPX/SDX 26000-100G series
• MPX/SDX 26000 series

Voor de overige modellen met een firmware ouder dan vermeld in de onderstaande lijst geldt dat deze wel kwetsbaar zijn:

• Citrix ADC and NetScaler Gateway version 12.1 ouder dan build 50.31
• Citrix ADC and NetScaler Gateway version 12.0 ouder dan build 60.9
• Citrix ADC and NetScaler Gateway version 11.1 ouder dan build 60.14
• Citrix ADC and NetScaler Gateway version 11.0 ouder dan build 72.17
• Citrix ADC and NetScaler Gateway version 10.5 ouder dan build 69.5

Voor deze modellen zijn firmware updates beschikbaar op de Citrix website: https://www.citrix.com/downloads/netscaler-adc/

Het platform en de versie van de Citrix ADC kunnen via de CLI worden opgevraagd met de commando’s ‘sh hardware’ en ‘sh version’:

Via de GUI is het platform te vinden in de hoofdpagina van de ADC:

De firmware versie is onder andere in de linkerbovenhoek onder het uitklapmenu van het ingelogde account te vinden:

Daarnaast heb ik een PowerShell script beschikbaar gemaakt waarmee eenvoudig het platform en de firmware versie opgevraagd kan worden: https://github.com/eltjovangulik/PowerShell

De syntax is als volgt:

.\nscheckversion.ps1 -nsip ipadres -adminaccount nsroot -adminpassword nsrootwachtwoord

Hierbij dient bij de parameter ipadres het IP adres van de NSIP van de Citrix ADC. De parameters adminaccount en adminpassword zijn niet verplicht. Wanneer deze weggelaten worden zal er getracht worden om met de default credentials in te loggen.

Meer informatie over de kwetsbaarheid

Deze kwetsbaarheid betreft een zogenaamde ‘Padding Oracle Vulnerability’ in de CBC gebaseerde versleuteling.

CBC staat voor Cipher Bock Chaining en is een blokversleutelingsmodus. In tegenstelling tot stroomversleuteling waarbij een boodschap bit voor bit versleuteld wordt, wordt bij het gebruik van blokversleuteling een blok van meerdere bits (ook wel de blokgrootte genoemd) tegelijk versleuteld met een coderingssleutel. De blokgrootte heeft hierbij altijd een vaste lengte. Hierdoor kan het dat er bits toegevoegd moeten worden aan het blok om aan de vast gedefinieerde blokgrootte te komen. Dit wordt Padding of in het Nederlands opvulling genoemd. Met de CBC modus van blokversleuteling wordt ieder blok eerst door exclusive OR (XOR) functie gehaald samen met het voorgaande blok, voordat het blok met de coderingssleutel wordt vercijferd. Dit is anders dan bij EBC (Electronic Code Book) waarbij ieder blok met dezelfde sleutel wordt vercijferd. Het probleem met ECB is dat wanneer er een opeenvolgende gelijke waarden versleuteld worden alle gecodeerde blokken ook identiek zullen zijn, terwijl dit bij het gebruik van de CBC modus niet het geval is.

Bij een Padding Oracle aanval, lekt het oracle (meestal de server) informatie over of padding correct of incorrect is, door een “invalid padding” foutmelding terug te geven.  Deze informatie kan vervolgens gebruikt worden de blokken via het orakel te ontsleutelen met behulp van de sleutel van het orakel, zonder de coderingssleutel te hoeven weten.

Naast het upgraden van de firmware is het mogelijk om gebruik te maken van een nieuwe versleutelingsmodus zoals bijvoorbeeld Galois/Counter Mode (GCM) welke niet vatbaar is voor de Oracle Padding kwetsbaarheid. Zie https://docs.citrix.com/en-us/netscaler/12-1/ssl/ciphers-available-on-the-citrix-adc-appliances voor welke versleutelingen beschikbaar zijn voor de verschillende ADC modellen en platformen.

Photo by Wout Vanacker on Unsplash

Monitoring Citrix Cloud

Sinds de introductie van XenApp en XenDesktop 7 levert Citrix de monitoring tool Director mee bij alle versies van hun software. Hiermee kunnen beheerders hun XenApp en XenDesktop omgeving monitoren en pro-actief beheren.

Met de introductie van Citrix Cloud hebben beheerders mogelijkheid om de monitoring data van XenApp & XenDesktop service en de daar opvolgende trends uit Director tot 90 dagen terug in te zien.

Maar wat nu als de trends en rapporten in Director niet voldoen?

Of wanneer je de data langer dan 90 dagen wilt opslaan en inzien?

Tot voor kort was je aangewezen op de custom reports van Director, maar sinds kort bied Citrix je ook de mogelijkheid om zelf direct de monitor database van Citrix aan te spreken.

Met OData kan de data uit de monitor database opgevraagd worden. Vervolgens kunnen we daar onze eigen queries op loslaten om rapporten te definiëren of om een eigen monitor dashboard te vullen.

OData is een protocol om data op te vragen die gebruikt maakt van standaard protocollen zoals HTTP en methodes zoals REST (REpresentational State Transfer).

Citrix maakt gebruik van token authenticatie om de data op te kunnen vragen. Hiervoor is een zogenaamd bearer token nodig. Dit bearer token kan aangevraagd worden via powershell en maakt gebruik van de API van Citrix Cloud.

Secure Client

Om een bearer token aan te vragen is een secure client nodig. Deze kan aangemaakt worden in Citrix Cloud bij Identity Management onder de kop API Access.

De secure client bestaat uit een ID en een bijbehorend Secret.

Bearer token

Nu we de secure client hebben kunnen we via PowerShell het bearer token aanmaken.

function GetBearerToken {
param (
[Parameter(Mandatory=$true)]
[string] $clientId,
[Parameter(Mandatory=$true)]
[string] $clientSecret
)

$postHeaders = @{“Content-Type”=”application/json”}
$body = @{
“ClientId”=$clientId;
“ClientSecret”=$clientSecret
}

$trustUrl = “https://trust.citrixworkspacesapi.net/root/tokens/clients”
$response = Invoke-RestMethod -Uri $trustUrl -Method POST -Body (ConvertTo-Json $body) -Headers $postHeaders
$bearerToken = $response.token
return $bearerToken;
}

$clientId = “ClientID”
$clientSecret = “ClientSecret”
$bearerToken = GetBearerToken $clientId $clientSecret
$token = “CwsAuth Bearer=”+$bearerToken

Opvragen data

Met het bearer token in bezit in de variabele $bearerToken kunnen we nu met PowerShell de data opvragen door invoke-webrequest aan te roepen.

Hiervoor is naast het bearer token ook een customer ID nodig. In mijn voorbeeld is dat ‘Admin7255’.

$headers = @{“Authorization” = “$token”; “Customer” = “Admin7255”}
$url = “https://Admin7255.xendesktop.net/Citrix/Monitor/OData/v4/Data/Users”
$result = Invoke-WebRequest -Uri $url -Headers $headers

In dit voorbeeld hebben we de Monitor database gevraagd om gegevens over de gebruikers.
Het resultaat in $result kunnen we vervolgens naar een bestand wegschrijven:

Uiteraard hoeven we geen PowerShell te gebruiken. Nu we de bearer token hebben kunnen we de data ook opvragen in bijvoorbeeld Excel of in PowerBI.

In het onderstaande voorbeeld maak ik gebruik van PowerBI desktop om de data op te halen

Start met het ophalen van de gegevens:

Kies hierbij niet voor een OData-feed, maar voor een lege query:

In de Power Query-editor kiezen we voor de geavanceerde editor

De Source is de Odata feed die we ook in Powershell gebruikt hebben alleen vraag ik hier niet data van over Gebruikers op, maar de over de Machines:

“https://Admin7255.xendesktop.net/Citrix/Monitor/OData/v4/Data/Machines”

Ook hier geven we in de header het bearer token en de customer ID op

Zodra de we query hebben opgeslagen kunnen we met de data aan de slag

Daarnaast kunnen we samen gestelde queries maken:

https://{customerID}.xendesktop.net/Citrix/monitor/odata/v4/data/Users?$filter=Sessions/any(session: session/LogOnDuration gt 600000)

We kunnen daar bijvoorbeeld een filter aan toevoegen, in dit geval vragen we de sessies op van gebruikers die langer dan 10 minuten over het inloggen hebben moeten wachten.

Uiteraard beperken de mogelijkheden zich niet tot de gegevens over de gebruikers of Machines in Citrix Cloud. Om uitgebreidere queries mogelijk te maken heeft Citrix het database schema van de Monitor Service vrijgegeven.

https://developer-docs.citrix.com/projects/monitor-service-odata-api/en/7.16/#monitor-service-schema

https://developer-docs.citrix.com/projects/monitor-service-odata-api/en/7.16/api-schema.png

Meer informatie over OData is beschikbaar op de website van OData op https://www.odata.org/

Windows 10 April 2018 update

Gisteren is Windows 10 Build 1803 met codenaam ‘Redstone 4’ uitgekomen. Officieel staat deze release bekend als ‘April 2018 update’.

Zoals ook in de vorige versies staat het buildnummer voor het jaar en de maand waarin de update uitgekomen is, 18 voor 2018 en 03 voor … tja… voor april dus blijkbaar…

Nieuwe features

Build 1803 brengt ons naast beveiligings- en bugfixes ook een scala aan nieuwe features. Niet al deze features zijn waarschijnlijk even relevant in de VDI wereld als in een thuisomgeving.

Zo is de nearby sharing feature een nieuw toegevoegde feature waarmee je gemakkelijk bestanden kan delen met ‘nearby’ devices via Bluetooth of Wifi.

nearby sharing

Timeline is een andere nieuwe feature die de mogelijkheid biedt om verder te gaan met werkzaamheden waaraan je bezig was op een ander Windows 10 device of Android of iOS device die verbonden is met je Microsoft Account.

Timeline

Known issues

Voordat je build 1803 uit gaat rollen op je Citrix powered VDI’s is het wel raadzaam om de known issues van Citrix in artikel CTX231942 door te nemen

Op het moment van schrijven zijn er bij Citrix negen zaken bekend die problemen kunnen opleveren in combinatie met deze nieuwe Windows 10 build.

Zo zijn er zoals te lezen valt nog steeds problemen met de cursor in combinatie met hoge DPI instellingen op de client. Dit blijft een aanhoudend probleem en Citrix adviseerd om te upgraden naar de laatste versie van de Citrix Receiver, versie 4.11. Voor de LTSR versie van Receiver werkt Citrix nog aan een passende oplossing.

Een andere die ik er uit wil pikken is issue 5: “Virtual Machine’s provisioned using MCS that use PvD for user data enter into a BSOD upon logon from ICA session or through the Console.”

De personal vdisk is een depcrecated feature: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/whats-new/removed-features.html en wordt zodoende niet meer ondersteund.  Zowel PvD als Appdisks zijn vervangen door Citrix App Layering (het vroegere Unidesk voor de overname door Citrix).

Verder is er een probleem bekend met het printen door middel van een door Citrix UPS gemapte XPS printer. Dit komt doordat de XPS viewer niet standaard mee geïnstalleerd wordt in in build 1803.

Conclusie

De april 2018 update van Windows 10 brengt ons een berg aan nieuwe features, maar zoals altijd is het devies om een goede pilot te draaien met de nieuwe build voordat je deze bedrijfsbreed uitrolt.

Vaarwel AppDNA

Afgelopen week heeft Citrix versie 7.17 van Xenapp en Xendesktop geintroduceerd. Daarmee hebben ze ook de lijst met deprecated features bijgewerkt.

Tot mijn grote verbazing stond ook AppDNA op de lijst om uit volgende versies van Xenapp en Xendesktop verwijderd te gaan worden.

Wat is AppDNA

Applicatie migratie projecten kunnen tijdrovend zijn. Er is veel tijd nodig om het applicatie landschap in kaar t te brengen en om te toetsen of de applicaties geschikt zijn voor bijvoorbeeld een migratie naar Windows 10 of Xenapp 7 omgeving met Windows Server 2016 door bijvoorbeeld het doen van applicatie intakes.

AppDNA, can minimize the time and effort required to verify app compatibility in the new OS. By automating the app compatibility checks for all apps within the virtual environment, you can save up to 90% of time on testing and remediation.

AppDNA kon hierin helpen door de applicaties te analyseren en te bepalen of de applicaties geschikt waren voor de nieuwe omgeving. Daarnaast kon er een risico analyse gedaan worden.

Na de analyse gaf AppDNA een overzicht met daarin drie classificaties, Red, Amber en Green.

  • Red; de applicaties is waarschijnlijk niet geschikt voor de nieuwe omgeving;
  • Amber, hierbij is de applicatie waarschijnlijk geschikt voor migratie echter heeft deze wel aandacht nodig;
  • Green, geeft aan dat de applicatie geschikt is voor gebruik in de nieuwe omgeving.

Meer informatie over AppDNA is te vinden op de Citrix website.

TLS 1.0 en TLS 1.1

Naast AppDNA staat ook de ondersteuning voor TLS 1.0 en 1.1 op de nominatielijst om verwijderd te worden uit de toekomstige versies van Xenapp en Xendesktop. Dit is op zich niet erg verwonderlijk gezien het dat TLS 1.0 al uit 1999 stamt en TLS 1.2 ook al weer meer dan 10 jaar oud is!

Inmiddels staat ook de opvolger van TLS 1.2, heel verwonderlijk TLS 1.3 genaamd al in de startblokken. Op dit moment is TLS 1.3 nog in draft, maar Cloudflare bijvoorbeeld heeft TLS 1.3 al beschikbaar gemaakt voor zijn klanten. Ook voor de Netscaler ADC is er een beta versie die ondersteuning bied voor TLS 1.3 al beschikbaar op aanvraag bij Citrix.

Meer info

Meer informatie over alle deprecated features is te vinden bij Citrix: https://docs.citrix.com/en-us/xenapp-and-xendesktop/current-release/whats-new/removed-features.html

Citrix lijft Cedexis in

Twee weken geleden kondigde Citrix aan Cedexis gekocht te hebben.

Ik moet bekennen dat ik persoonlijk nog nooit gehoord had van Cedexis voordat ik het tweet van Citrix  en het daarop volgende persbericht had gelezen.

In de factsheet PDF van Cedexis wordt Citrix wel al genoemd:

ADC solutions, however, including industry veterans and leaders like F5 and Citrix Netscaler, were not designed for today’s modern, distributed applications. Contemporary architecture demands a cloud-native system:  a truly software-defined delivery platform that enables IT Ops, Developers, and DevOps teams to automate and optimize without having to commit to monolithic system replacements and expenses.

De productlijn van Cedexis bestaat uit meerdere componenten die samen het Cedexis Applicatie Delivery Platform, ADP, vormen.

Je kunt de technology van Cedexis vergelijken met de navigatie app Waze.

Met Waze wordt je route in realtime dynamisch aangepast aan de hand van grote hoeveelheiden data en informatie die wordt verzameld door alle Waze gebruikers.

Die productlijn bestaat onder andere uit de volgende drie componenten:

Radar

Radar verzamelt real-time experience data van 50.000 netwerken wereldwijd. Met deze data kan het ADP de applicatie delivery voorspellen en verzekeren dat het juiste pad gekozen wordt op basis van deze al real-time data. Volgens Cedexis is Radar ’s werelds grootste user experience measurement netwerk.

Deze statistieken zijn live te bekijken via https://live.cedexis.com/

Sonar

In tegenstelling tot Radar is Sonar een real-time, synthetische monitoring oplossing die de gezondheid van de onderliggend resources analyseerd en controleerd of deze niet overbelast worden of voor onderhoud offline gehaald zijn.

Fusion

Fusion kan gebruik maken van 3rd party data voor zijn beslissingsmatrix en daarmee het optimale pad voor het verkeer uit te zetten.

Hiervoor kan bijvoorbeeld gebruik gemaakt worden van AWS Cloudwatch data of bijvoorbeeld HTTP GET metrics.

Ik ben benieuwd te zien hoe Citrix de technologie van Cedexis gaat integreren in hun bestaande Netscaler portofolio, Netscaler ADC en SD-WAN.

Citrix zou bijvoorbeeld de GSLB functionaliteit kunnen uitbreiden met de metrics van Cedexis. Voor Netscaler zou dat SD-WAN bijvoorbeeld kunnen betekenen dat de de optimale route niet alleen bepaald wordt op basis van bijvoorbeeld de kosten van de verbinding maar door gebruik te maken van Cedexis technologieën ook op basis van beschikbaarheid van de verbinding.

Loadbalancing Ivanti Relay servers

Sinds versie 2012 van RES Workspace Manager heeft RES de mogelijkheid om gebruik te maken van de optionele RES Relay servers. Hiermee verbinden de RES agents niet direct naar de database, maar via één of meerdere Relay servers. In deze blog zal ik uitleggen hoe je de Loadbalancing van de Relay servers kan regelen met behulp van de Netscalers van Citrix.

Voordelen RES relay server

Ivanti geeft aan dat in een single-site topology het gebruik van Relay servers de load op de datastore kan helpen verminderen. De Relay server chachet de informatie uit de datastore en kan hiermee een groot aantal agents bedienen.

Decreasing Datastore load and increasing scalability

Een additioneel voordeel is dat er door het te maken van meerdere Relay servers het niet noodzakelijk is om een database cluster op te zetten voor de datastore om zodoende een hoogbeschikbare omgeving verkrijgen.

De Workspace Control omgeving wordt daarnaast veiliger omdat de agents geen directe verbinding meer nodig hebben naar de database. De Relay servers maken daarentegen gebruik een environment password voor de communicatie met de Agents. Dit environment password geeft namelijk geen toegang tot de database.

Beperkingen

Het gebruik van de Ivanti Relay servers in de standaard opzet, zonder loadbalancing, heeft een aantal beperkingen.

In het eerste geval is er geen monitoring op de backend services. Daarnaast wordt er geen load distributie gedaan. Wanneer een agent verbinding wil maken met een Relay server zal hij verbinding maken met de eerste server die antwoord, ongeacht zijn load.

 Selected connection methods are handled in order of appearance; and the Agent will stop looking for additional connections as soon as a valid connection is found.

Wanneer we de Relay servers via de Netscaler Loadbalancen hebben we beide beperkingen ondervangen. Door middel van een Netscaler monitor kunnen we de status van de Relay server in de gaten houden en verkeer, in het geval van problemen, naar de Relay servers sturen die wel online zijn.

Configuratie

In de volgende alinea’s zal ik laten zien hoe een simpele loadbalancing setup voor de Relay servers opgezet kan worden. In de voorbeelden ga ik er vanuit dat er reeds een werkende Workspace Control omgeving inclusief twee of meer Relay servers bestaat evenals een Netscaler omgeving met één of meerdere Netscalers.

Stap 1

We beginnen met het aanmaken van de serverobjecten voor in de Netscaler voor de Relay servers.

Stap 2

Als de server objecten zijn aangemaakt kunnen we een monitor aanmaken. Met de monitor kunnen we de status van de Relay servers controleren en bepalen of de Relay servers gezond zijn en of we dus verkeer naar de server kunnen sturen.

Standaard gebruikt de Relay server TCP poort 1942. We kunnen dit controleren op de Relay server door de ‘Relay Server Configuration Tool’ te raadplegen

of via de commandline met ‘Netstat’

Bij het aanmaken van de monitor hoeven we enkel de poort op te geven en niet het IP adres. Wanneer we het IP adres leeg maken zal de monitor het IP adres van de serverobjecten die we in stap 1 aangemaakt hebben gebruiken.

Stap 3

Nu de we de server objecten en de monitor hebben kunnen we een Service Group aanmaken voor beide.

Koppel de twee server objecten als Service Group Member aan de Service Group.

Nu de Server Objecten gekoppeld zijn kunnen we de monitor toevoegen aan de Service Group.

Onder Service group -> Group Members -> monitor details kun je nu zien of de monitor probes succesvol zijn. Dit betekend dat de Relay server gezond is en verbindingen van de agents kan accepteren.

Indien we alles correct hebben geconfigureerd zal de Service Group de status ‘UP’ hebben.

Stap 4

Nu we de Service Group aangemaakt hebben kunnen we de loadbalancing vServer aanmaken. Hiervoor is een vrij IP adres nodig of een we kunnen een IP adres hergebruiken zolang de IP adres en poort combinatie maar uniek zijn.

Zoals je in het onderstaande afbeelding kunt zien hebben we bijvoorbeeld al een vServer voor de load balancing voor Storefront aangemaakt. Deze kunnen we hergebruiken omdat deze alleen op poort 443 luistert. Het IP adres voor de Navision vServer is bijvoorbeeld niet beschikbaar omdat we daar op alle poorten luisteren.

Als de vServer is aangemaakt zal deze zowel bij ‘State’ als bij de ‘Effective’ state de status ‘UP’ geven.

Stap 5

De volgende stap na de basis configuratie van de vServer, is het instellen van de de Load Balancing methode.

Ik heb in dit voorbeeld gekozen voor ‘leastconnection’ gekozen waardoor de load netjes over alle beschikbare Relay servers zal worden verdeeld.

Het ‘leastconnection’ algoritme zal proberen om alle verbindingen netjes over de Relay servers te verdelen. Het algoritme gebruikt de volgende expressie om te bepalen naar welke server de verbinding gestuurd zal worden:

N = het aantal actieve verbindingen

Wanneer alle Relay servers het zelfde aantal actieve verbindingen hebben zal het algoritme in Round Robin gebruiken om de load te verdelen.

Stap 6

Nu de Loadbalancing vServer is actief is kunnen in Ivanti Workspace Control de Agents laten verbinden naar het IP adres van de vServer. Desgewenst kunnen we in DNS aan A record aanmaken naar bijvoorbeeld resrelay.domein.local en op FQDN verbinden.

In de controle stap kunnen we verifiëren of de Agent nog verbinding heeft met de Relay Server en we kunnen de status controleren in de Netscaler.

Hier is nu ook te zien dat er er momenteel twee connecties zijn en dat deze netjes verdeeld zijn over de beide Relay Servers.

Meer informatie over het de installatie van Relay servers is te vinden op de Community website van Ivanti.