by Ray Davis, CTA, Jacksonville CUGC Leader

Most of everyone that does Citrix understands that security of the XML traffic between Delivery Controllers/Citrix Cloud Connectors and StoreFront typically is a must. There may be some situations where some folks may not need it, but that is rare. Things like:

• It’s only used internally and has no gateway.
• Gateway is used, but again it’s all internally.
• VPN is used from laptop setup, and they hit the internal Citrix Environment.
• The organization is new to Citrix and may not understand all the moving parts. To them, things work, and it may be out of sight, and out of mind.

I am sure there are many other cases. But I ran into a few in the last year or so. I also secure it in the bullets I listed above to cover any bases. I found out that in some cases, the company security team will scan the environment with their tools, and it will show up in a report, which will cause you to secure it anyway. My thoughts are to do it in the beginning, and it is completed. Some may disagree, but that is ok 😊. When doing Citrix deployments for clients, I always try to follow Citrix Security best practices. I will list a comprehensive list of what I follow that I put together through the years at the end of the blog.

Long way

I would say most of you understand this way, and this is not anything new. However, I will review it anyway and give you a working example, just in case. Many blogs will cover this same concept online. It’s a typical case, and many folks have written it up. This is assuming you don’t have your Director Servers in the DDC as well. I have seen some occasions where this was the case. Some folks say that is bad, and others say it’s ok. In my opinion, it all depends on the environment’s size and resources. I would preach to separate them from my perspective around security considerations, no need to put IIS on a delivery controller IMHO. Enroll for a Computer Cert, but at the time, this is what I had. So, I request a Cert in my case.

Note: WebServer does not have to be selected. At the time, It was what I used.

Pick the CA based on the location that will match your environment.

1. Open PowerShell and run this 
2. Grab the Thumprint 
3. Set-Location Cert:\LocalMachine\My 
4. Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint -AutoSize 

5. You can also get it a bit cleaner with this. (Either way works)
   1. Get-ChildItem -Path Cert:\LocalMachine\my | Select-Object FriendlyName, Thumbprint, Subject, NotBefore, NotAfter

6. Locate the App ID of the Citrix Broker Services (Cloud Connector). You can do it with “broker” or “Citrix broker Service” it depends on if you are using the command for the older CVAD version vs CR version. However, this is a cloud connector either one works—just extra information.
7. Get-WmiObject -Class Win32_Product | Select-String -Pattern “broker.” 
8. Get-WmiObject -Class Win32_Product | Select-String -Pattern “citrix broker service.”

9. Within PowerShell, do this:
   • netsh http>
   • If you have an existing cert, run this to remove it:
     • delete sslcert ipport=0.0.0.0:443 (use option C if you don’t want to do this) 
10. Otherwise:
    • add sslcert ipport=0.0.0.0:443 certhash=17BE86B8271FF234662D47DBAC61D688D4A6C0FA appid= {ff8980ed-53ce-dcf4-3879-4ee77227aaab}
11. If you get an error and don’t want to delete the old one, use this instead. 
    • Update sslcert ipport=0.0.0.0:443 certhash=17BE86B8271FF234662D47DBAC61D688D4A6C0FA appid={ff8980ed-53ce-dcf4-3879-4ee77227aaab}
12. Show sllcert

Examples 
CTXCC01.Lab.local
add sslcert ipport=0.0.0.0:443 certhash= BCD7BF8EA1C491E7D4FFF3086975B10A67CDA4E7 appid= {DE0898FF-EC35-4FCD-8397-E47E2772AABA}

In the Registry, you will see two keys in this location. If you want to ignore the HTTP traffic, Create a DWORD with the name XMLServicesEnableNonSSL and value 0x0

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer

• XmlServicePort = 80
• XmlServicesSslPort = 443
• Add XMLServicesEnableNonSSL and value 0x0

Short way and much more manageable.

I had a couple of questions and reached out to the World of EUC on things. James Kindon sent me a Github script that does all this in one shot. I was amazed, and I chose to do this to show you the ease of automation.

• The script is located here and does this “Handles the assignment of certificates required for both Citrix Brokers and Citrix Cloud Connectors as well as enabling or disabling HTTP based XML Access
• Combines some of the work from Stephane Thirion found here https://www.archy.net/enable-ssl-on-xendesktop-7-x-xml-service/ as well as some misc code snippets picked up along the way”Citrix/EnableSSL.ps1 at master · JamesKindon/Citrix · GitHub

• Pull down the script, and put it in a location on the DDC/CC. There are many parameters with different options. The one I needed was this. .\EnableSSL_XML.ps1 -EnableSSL -DisableHTTP
  • Line 29 – PS C:\> .\EnableSSL.ps1 -EnableSSL -DisableHTTP
  • The above example will prompt for a certificate and, once selected, will create the appropriate SSL binding. It will also disable answering XML requests on HTTP
  • Assing the DDC/CC a machine cert and follow this.
  • Note: I did this on an on-prem Delivery Controller this time around. The same applies to the Cloud Connector, though.

Then you can run “.\EnableSSL_XML.ps1 -ValidateSSLStatus” to check the status.

That’s all! 😊

I use this method for all my clients now, it quick and does the job very well.

I want to test it over port 80 and get some essential network traffic findings. I would like to see the outcome and show you as well.

What I expect to happen is when I launch a Desktop/App, the StoreFront server will contact the DDC in this example over port 80, as I specified above, to show you that the script disabled it from working even though I said in the SF console to use it. It should error out and offer something in the logs.

This is a packet capture. You can see SF tried to reach out over port 80

Then I received this nice but nasty error.

Ok, so we knew that would happen. Now I will put it back to 443.

Reference:

How to Enable SSL on Cloud Connectors to Secure XML Traffic (citrix.com)

Citrix Cloud – Enabling SSL on Cloud Connector to secure XML/STA Traffic. – David Wilkinson

This is what I always followed as I applied it to the cloud connectors as well.

HowTo: Enable SSL and Secure XML Traffic on Citrix Delivery Controllers – Easy Method (ferroquesystems.com)

Biggest reference was this (One stop show- that does it all) Citrix/EnableSSL.ps1 at master · JamesKindon/Citrix · GitHub

As promised, here are the security checks that I follow, the list grows as I discover new things.

High level of security checks

User Layer

1. Device Lockdown
2. GPO hardening- Security baselines guide | Microsoft Learn
3. Auditing for event logs –
   1.  Security auditing (Windows 10) | Microsoft Learn
   1. Recommended advanced audit logging – Truesec
4. Endpoint logging with a SIEM
5. Proper path cycle (Patch Tuesday goes to test/dev, next week is prod-unless it’s a Zero day)
   1. Windows Server Patching: Best Practices – TechNet Articles – United States (English) – TechNet Wiki (microsoft.com)
6. Citrix Workspace App Security
   1. Secure communications | Citrix Workspace app for Windows
   1. Security update SSON CWA
7. Windows TLS Ciphers-
   1. Cipher Suites in TLS/SSL (Schannel SSP) – Win32 apps | Microsoft Learn
8. CWA App protection (Workspace side)
   • Tech Brief: App protection | Citrix Tech Zone
   • PoC Guide: App protection policies | Citrix Tech ZoneConfigure | Citrix Workspace app for Windows
   • Possible issues – screen sharing on applications (Teams, WebEx and GoToMeeting) will not display screen properly until Workspace is minimized. (citrix.com)
9. CWA Secure ICA File session launch
   • Enabled “Secure ICA File Session launch” This will block the ICA files from being opened by browsers that can’t use the ICA in memory
     • ICA File Settings > RemoveICAFile (remove ICA files, if downloaded)
   • • Improved ICA file security
10. CWA TLS Support
    • TLS settings

Access layer

1. NetScaler Gateway URL scans
   • Security headers
     • Analyse your HTTP response headers (securityheaders.com)
     • Citrix ADC – Latest Insights about Security Headers – Julian Jakob
     • SSL Labs – Qualys SSL Labs
     • Legacy ciphers – legacy ciphers (SSL2, SSL3, DES, 3DES, MD5 and RC4)
     • Use TLS 1.2 \ TLS 1.3
     • VIP and Services need certs for End to End encryption.
     • Change default nsroot, LOM, Nsrecover
     • Replace default self-signed SSL cert (NSIP, LOM SDX)
     • Keep Firmware updated around CVE- applies to LOM as well.
     • Separate NSIP traffic from SNIP (PBR)
       • Separating NetScaler Management and Data Traffic for DISA STIGs | Citrix Blogs
     • Use LDAPS for Admin login at least.
     • Send logs to Log server.
       • Configuring Citrix ADC appliance for audit logging | Citrix ADC 13.1
   • Addressing Security headers –
   • NetScaler Security Best Practices and TLS Best Practices
     • Best practices for Citrix ADC MPX, VPX, and SDX security
     • Tech Paper: Networking SSL / TLS Best Practices | Citrix Tech Zone

2. Strong Authentication
   • MFA\2factor
   • LDAPS only – not ldap by all means

3. Encryption- XLM Traffic
   • Ensure that your XML traffic from the Delivery Controller or Cloud Connector to StoreFront servers is always encrypted
   • Secure XML traffic between StoreFront and Delivery Controller 7.x (citrix.com)
   • https://docs.citrix.com/en-us/citrix-daas/secure.html#enforce-https-or-http-traffic
   • Enforce HTTPS traffic only SSL configuration on VDA (citrix.com)

3a. Cloud Connector ( Windows)

• https://docs.citrix.com/en-us/citrix-daas/secure.html#xml-trust
• https://docs.citrix.com/en-us/citrix-daas/secure.html#enforce-https-or-http-traffic

4. Store Front SSL

• Where possible add SSL on BaseURL for storefront.
• Unless doing SSL offloading(but make sure the NS service had SSL/update Ciphers)
  • End-to-end Encryption
• • Secure your StoreFront deployment | StoreFront 2203 (citrix.com)

5. VDA/HDX Encryption
SSL configuration on VDA (citrix.com)

Resource layer

1. Harding Windows Images

2. Hide Admin shares
   • On Windows systems, there are typically “admin” shares called c$ (for example) for admins to connect to the c: drive remotely. However, these shares are now by default open to all interactive users, which includes users logged on to Citrix Virtual Apps systems. This means a user can access the local drive by browsing to \\LOCALHOST\C$ or the network loopback address of \\127.0.0.1\C$
   • In order to prevent this, it is recommended to set a Registry value via GPO or in the image so that the behavior reverts to that used previously. The Registry value is a hexadecimal entry so should be imported from a .reg file rather than entered by hand
   • Once this is in place, users will no longer be able to connect to these hidden shares and gain entry to local drives. It will also block these connections from Chrome, Internet Explorer, Microsoft Edge or Edge Chromium
   • Administrators can still connect to these shares remotely, which was the original purpose of these hidden shares
   • Admin shares available to non-administrative users over loopback address (microsoft.com)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity]
“SrvsvcShareAdminConnect”=hex:01,00,04,80,64,00,00,00,70,00,00,00,00,00,00,00,\
14,00,00,00,02,00,50,00,03,00,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,\
00,00,05,20,00,00,00,20,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,\
00,05,20,00,00,00,25,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,00,\
05,20,00,00,00,27,02,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,\
00,00,00,05,12,00,00,00

3. Set WinRM HTTPS(if used)
   • How to configure WINRM for HTTPS – Windows Client | Microsoft Learn
4. Set Auditing policy Best practice on VDA
   • Audit Policy Recommendations | Microsoft Learn
5. Locked down TLS and Windows TLS Ciphers
   • Cipher Suites in TLS/SSL (Schannel SSP) – Win32 apps | Microsoft Learn
   • Nartac Software – IIS Crypto
6. Pathing and updates
   • Test/Dev/QA/Prod approach
7. Antivirus Software
   • AV is needed on all products to continue to provide a first line of defense.
   • Tech Paper: Endpoint Security, Antivirus, and Antimalware Best Practices (citrix.com)

Common Criteria Certification Information – Citrix
Securing Citrix Virtual Apps and Desktops Environments – Citrix
System Hardening Guidance for XenApp and XenDesktop (citrix.com)
VDA Hardening – Tech Paper: Citrix VDA Operating System Hardening Guide

8. Citrix Lock down policies
   • VDI Broker Security Analysis Q4 2022 – VDISEC
   • Citrix Offers Template for securing Citrix Polices within Citrix Studio
   • Virtual channel security enforcement > 2203 and higher
     • Virtual Channel names and process allowing steps
     • Making Your Citrix Policies Secure
9. Citrix Session Recordions
   • Session Recording provides IT teams with the ability to record and replay video of what transpired during a given users session
   • This ability may not be needed for all users. It can be enabled for key individuals, user groups, or when accessing sensitive applications, desktops, or resources. Many takeaways can be gleaned from these recordings that might not be possible with just Windows event and application logs
   • Scalability considerations | Session Recording 2203 LTSR (citrix.com)
   • Scalability considerations | Session Recording 2210 (citrix.com)
   • TLS and ciphers security still applies.
   • Security recommendations | Session Recording 2210 (citrix.com)
   • Security recommendations | Session Recording 2203 LTSR (citrix.com)

10. Watermarking
    For sessions that have a user accessing sensitive data, a great deterrent to having the data be stolen is a watermark. Especially if the watermark can uniquely identify the user. Citrix enables admins to configure what to display. You can display:
    • User logon name
    • Client IP address
    • VDA IP address
    • VDA host name
    • Login timestamp
    • Customized text.
    • Session watermark policy settings | Reference (citrix.com)
11. VDA Security Hardening CitrixTech Zone

Control Layer

1. Ensure Availability

When deploying any solution, components must be deployed in a highly available manner. Having services that are suffering constant outages due to single points of failure is poor practice. Therefore, using the N+1 approach to capacity ensures that there is enough resource available during logon and log off storms. But there is an acceptable level of component loss to retain the ‘good’ user experience. Now, most customers follow N+1 in terms of planning the amount of resources that need to be available. However, depending on the tolerable level of risk, this may be N+2.

Also, to ensure there are enough resources available to handle the user load, components should be separated off onto dedicated virtual machines. It is bad practice to run shared components on virtual machines, not only from a performance perspective, but also security. Key components from a Citrix perspective are as follows, but not limited to:

• StoreFront
• Delivery Controllers
• SQL Server
• Federated Authentication Service
• Director
• License Server
  • Change Self-Signed Cert
• Cloud Connectors

2. Citrix Printing security
   • Best practices, security considerations, and default operations (citrix.com)
3. Citrix FAS security
   • https://docs.citrix.com/en-us/federated-authentication-service/config-manage/security.html#security-considerations
   • The Enrollment agents list contains only FAS servers (remove everyone)
   • Security access controls list

• List only SF servers
• If possible, list on the VDAs (create groups if needed)
• If Possible, list users that use the SF servers
• Change the Cryptogrpahy Key Size from 1024 to 2048 Bit

• Modify the Extended Key Usage (EKU) from “All” to “Smart Card Logon” only

• DCOM Firewall

Host Layer

1. Hardware Separation
   • Separate workloads into unique clusters and ensure that workloads hosting the same data classification are retained within those unique clusters. If an attacker broke into the hypervisor layer somehow, higher classifications of data are not compromised.
2. Network Separation
   Breaking down workloads into individual subnets that are logically separated, can dramatically reduce the impact, or spread of an attack. Usually, these subnet layouts are a perfect place to start:
   • Access Components. Small subnet compromising of the ADC IP addresses and call-back gateway.
   • Citrix Infrastructure. The Citrix infrastructure subnet depending on the infrastructure being deployed would include the following; StoreFront, Cloud Connectors/Controllers, Director servers, Citrix ADM.
   • Supporting Infrastructure. Depending on which infrastructure components are required, these services are prime examples for separation; SQL servers, Jump servers, and Licensing servers. This is dependent on your compliance needs.
   • VDA Subnets. There is no right or wrong answer when sizing the VDA subnets. In the past, we have used historical data to guide us around PVS subnet sizing. Over time, PVS recommended practices have evolved. The main thing to note is that subnet sizing must be allocated based on the number of users and VDAs and the security context that they are accessing. Placing users with a similar risk profile into a single subnet can also ensure that each of these subnets can be separated by a firewall.
3. Firewalls
   Firewalls are one of the primary elements of implementing security in an environment. Implementing host-based and network-based firewalls will introduce significant operational overhead. Implementing two levels of firewalls from both a host-based and network-level will allow for separation of duties. This step allows an application to communicate from one server to another. Any firewall rules must be well documented and clearly marked as to which roles or functions are assigned. This detail will assist you in getting approvals for exceptions from your security and network teams.

Secure Citrix Cloud platform
Secure Deployment Guide for the Citrix Cloud Platform

Citrix DaaS Technical Security Overview
Technical security overview | Citrix DaaS          
Delegated administration | Citrix DaaS

Citrix Site Analytics Delegated Admins
https://docs.citrix.com/en-us/citrix-daas/monitor/permissions.html

Citrix DaaS Reference Architecture
Reference Architecture: Citrix DaaS | Citrix Tech Zone