Overview

In my role as a Senior Solutions Architect in Performance Engineering at Nutanix our team does a lot of testing with various configurations of Nutanix AOS, AHV, and different EUC endpoint options. Part of this requires us to re-image our testing clusters to ensure that they are in a clean and standard state ready for us to test on.

This post will walk you through one of the ways you can achieve that using Containers and Ansible enabling you to execute an Ansible Playbook from your local Visual Studio Code IDE and watch as the magic happens!

Required Components

Foundation Virtual Machine

First, you will need a Foundation VM in place. The reason for this is that the Foundation VM is what, well, drives the foundation of the cluster.

What we will be doing with the workflow is shown below.

To install a Foundation VM head over to the My Nutanix portal and open up the Support and Insights page. Then select Downloads and finally Foundation. Here you will see various options for downloading a standalone Foundation VM image. Pick the option that suits the hypervisor you wish to run the VM on, download and set up the appliance following the Nutanix documentation.

Once done you should be able to connect to your new Foundation VM on port 8000 http://foundation_vm_ip:8000.

Now, at this point you could manually go through the steps of filling out the UI and re-imaging your cluster but where’s the fun in that!

Container Platform

You will also need a container platform on your laptop in order for VS Code to be able to open your code in a re-usable and consistent container. Doing this will enable you to automatically download and install the required components to build and configure your clusters.

I use a MacBook but Rancher supports MacOS, Windows and Linux making it a good option. Head over to the Rancher download page and go ahead and install it.

Visual Studio Code Extension

The last thing you will need is the Dev Containers Visual Studio Code extension.

Click the extensions icon in VS Code, search for Dev Containers and install it.

Foundation Your Cluster

With all the pre-reqs in place let’s go ahead and start to have some VS Code fun!

Build The Container

Open up a new folder in VS Code and create a top level folder called .devcontainer. When you instruct VSCode to open your folder in a container it will use the definitions scoped out here to build your container for you automatically.

Within the folder you will create 2 files detailed below.

More information on these file definitions can be found here

In these files you will need to define what Docker Container variant you want to install as well as the version of Ansible and any other tools you want in your Container. Microsoft have some good documentation on creating Dev Containers here but if you want a quick start set of files I have created both in my GitHub Repo here that you can download and use.

Once you have these in place you can test your new container by using the command Dev Containers: Rebuild and Reopen in Container from VS Code.

This will build and open your code in a new container and allow you to open a bash terminal within VS Code directly in the container. You can check the container is built and running by looking in Rancher Desktop.

You will also see that Ansible is installed within the container as part of the build.

Install Nutanix Ansible Module

Next you will want to install the Nutanix Ansible Module into your container. This will presist unless you rebuild your container (change the DockerFile or devcontainer.json) so you should only need to do this once.

Open a bash terminal in your container and enter the following commands:

cd ~
git clone https://github.com/nutanix/nutanix.ansible.git
cd nutanix.ansible
git checkout v1.9.1 -b v1.9.1
python -m venv venv
. venv/bin/activate
ansible-galaxy collection build
ansible-galaxy collection install nutanix-ncp-1.9.1.tar.gz

Define Foundation Playbook

Next you want to define a Playbook that Ansible will use to Foundation your cluster. Luckily for us the kind folk at Nutanix have given us a bunch of examples to use here

Create a file in your container called filename.yml and copy the contents of this file into it substituting the values for those of your environment. Duplicate the blocks and nodes sections to mirror what you are going to be re-imaging.

Most of the details in the yml file are self-explanatory but a couple of key fields I would like to point out are below.

Running The Playbook

Ok, so you have everything defined, and you are ready to Foundation your new cluster. It’s as simple as running the following command.

ansible-playbook playbook_file_name.yml

That’s it, Ansible will take the contents of your playbook, connect to the Foundation VM, pass all that content over and start the process of re-imaging your new cluster.

Taking It Further

Whilst this is great and a nice way to be able to automate the imaging of your Nutanix clusters if you think a little broader there are a number of ways to make this process slicker by introducing more tools into the mix. Some of my thoughts on this are below.

PowerShell For The Win

If you put PowerShell into your container you are able to use this to automatically build and execute the yml files as well as integrate the script into your reporting tool set (think slack for build notifications). To get PowerShell into your container you can create a bash script to execute on container build with the following content.

architecture="$(uname -m)"
case ${architecture} in
    x86_64) architecture="amd64";;
    aarch64 | armv8*) architecture="arm64";;
esac

if [ "${architecture}" = "arm64" ]; then
    echo "Architecture is ARM"
    posh="https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/powershell-7.3.0-linux-arm64.tar.gz"
else
    echo "Architecture is X86_64"
    posh="https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/powershell-7.3.0-linux-x64.tar.gz"
fi

echo "Downloading PowerShell from $posh"
curl -L -o /tmp/powershell.tar.gz $posh

echo "Installing PowerShell"
sudo mkdir -p /opt/microsoft/powershell/7
sudo tar zxf /tmp/powershell.tar.gz -C /opt/microsoft/powershell/7
sudo chmod +x /opt/microsoft/powershell/7/pwsh
sudo ln -s /opt/microsoft/powershell/7/pwsh /usr/bin/pwsh

Once you have this you can use the Invoke-RestMethod Cmdlet to pull data back from foundation before starting the Ansible playbook and use the extra-vars parameter to pass in data you have gathered from PowerShell.

The Nutanix Installer File

One of the obvious things with the above process is that you are hard coding a Nutanix Installer into the yml file. However, if you look at the Foundation API Reference here you can see there are options for getting available images or even uploading them.

If you think about this with PowerShell you could take the process further and achieve something like the below.

This gives you the ability to have a single script that will gather information at runtime for the entire build process ensuring that your automation work is re-usable and consistent.

Going Even Further

One of the issues with running this type of thing in a container is the additional tasks you have to perform once the cluster is initially built. Some typical tasks would be

• Register the cluster with Prism Central
• Create Storage Containers
• Create Networking
• Connect to Citrix with Hosting Connection

With the new API driven Citrix Configuration ability as well as the Nutanix APIs you can now do all of this from within a simple container fully automated. The below is just one way you could do this with PowerShell, Ansible and a Container.

With the above you can see that it is possible to build an automation wrapper to use with any cluster and achieve an end-to-end automated build from zero to a Citrix ready cluster, all is takes is a little time and some imagination!

Conclusion

The above may not be perfect. My Ansible skills are slim to say the least as are my PowerShell coding skills, but I have found that this is a good balance of easy to manage code and getting things done in an automated and consistent manner.

Please, if you have a better way to do this I am all ears, feel free to get in touch.

Thanks to “The Doc” Sven for all his help in getting this working!

Overview

Security is a big thing, always has been and always will be but when you tie security with a Citrix environment things get a little tougher. By nature, Citrix environments are typically an easy target for attackers, and they will try to get a foot hold in your environment and then spread out from there to the rest of your network. This is called Lateral Movement and is a common technique used my many attackers to get deeper and deeper into your world.

I have written about how to prevent lateral movement before, and you can read that here but what if you want to go a step further. Enter Network Segmentation.

What the hell is that you might ask, and why would I need to know about that in a Citrix Environment?

Wikipedia to the rescue, you can find a pretty decent starting point on network segmentation (NetSeg) here, so I would suggest reading that before you carry on with this post, so you have a basic understanding of what we are trying to achieve with this.

Network Segmentation

In essence, Network Segmentation does exactly what it says on the tin. You want to be able to split your network (or in this case your Citrix environment) into segments then define rules regarding the network traffic you want to allow in and out of that “segment” whilst blocking everything else.

Think about Citrix StoreFront as an example. You will want to allow port 443 into the servers from your defined user networks but not much else. The StoreFront servers will need to be able to talk to each other for subscription replication but outbound they may only want to be able to talk to the domain as an example. Now this is not an exhaustive list of the networking requirements but just an example to get the idea over.

What you want to be able to do is define all these rules so that you are only allowing the required traffic to move across your network and blocking everything else. This will stop attackers moving about your environment and taking advantage of a weak security posture.

This is easier said that done, I get that but implementing this will go a long way in making your platform more secure.

Citrix provides an exhaustive list of ports and protocols associated with all CVAD components. This document is regularly updated as component changes are implemented and is a good reference guide. Make sure that you map out your network requirements before starting out down this road as it will help reduce the chance of you pushing a policy that will break your environment.

Nutanix Flow Network Security

Since joining Nutanix as a Senior Solutions Architect I have been fortunate enough to get to play around with pretty much all the awesome technology that the engineers here come up with. One of these products is Nutanix Flow Network Security.

Here is the low down on what Flow Network Security is.

Flow Network Security delivers advanced networking and security services for AHV VMs, providing visibility into the virtual network, application-centric protection from network threats, and automation of common networking operations.

Fully integrated into AHV virtualization and the Nutanix Cloud Platform, Flow Network Security allows organizations to deploy software-defined virtual networking without installing additional products that have separate management and independent software maintenance requirements.

Flow Network Security provides application-centric policies that enable complete visibility and traffic control. This policy model allows administrators to implement fine-grained rules regarding traffic sources and destinations, or microsegmentation. These same policies make it possible to visualize traffic flowing within and between VMs. This granular level of control is an important part of a defense-in-depth strategy against modern datacenter threats.

Flow Network Security protects against new threats designed to spread laterally from one system to another in the same datacenter. Because perimeter-based firewalls traditionally only protect the environment from external threats, it can be difficult to repurpose them to protect internal traffic. Flow Network Security applies security rules between all applications and VMs in the datacenter, adding internal protection behind your perimeter firewall.

Implementing Nutanix Flow Network Security for Citrix Virtual Apps and Desktops

There is a great guide on the Nutanix documentation portal that will get you going with setting up Flow Network Security.

You can find the link to it here and the best thing is you can download it as a PDF and take it offline for some bedtime reading!!

Conclusion

Securing your Citrix Virtual Apps and Desktops environment is tough but by using products like Nutanix Flow Network Segmentation you can make things a little easier. I have found the configuration and implementation of the product really easy and intuitive and very good at improving your security posture right from the Prism Central interface.

Word of warning though, MAKE SURE YOU MAP THINGS OUT FIRST! Whilst implementing this I got bitten a few times by missing a port or protocol from the allow list so double-check your network diagram before applying the policies to ensure no downtime!

Thanks for reading.

Overview

Over the past few years security is becoming more and more of an issue to us as professionals who maintain and manage End User Computing Environments. This can often be over whelming and fast become like your chasing your tail as threats never seem to end.

There are, however, some excellent resources out there that can help you with this quest and one of them is the Center for Internet Security (CIS).

During the rest of this post I will explain what the CIS is, how to implement some of their guidelines (both free and paid for) and try to explain how this will help you to make your EUC environment more secure.

What is the Center for Internet Security

First and foremost, you can find their site here. This is what they say about themselves:

The Center for Internet Security, Inc. (CIS®) makes the connected world a safer place for people, businesses, and governments through our core competencies of collaboration and innovation. We are a community-driven nonprofit, responsible for the CIS Controls® and CIS Benchmarks™, globally recognized best practices for securing IT systems and data. We lead a global community of IT professionals to continuously evolve these standards and provide products and services to proactively safeguard against emerging threats. Our CIS Hardened Images® provide secure, on-demand, scalable computing environments in the cloud.

In essence, they are a community driven project that will give you configuration settings to make your platforms more secure, be warned however, there are A LOT of them (settings I mean).

What CIS Covers

The CIS Benchmarks there currently cover pretty much everything you will touch from an EUC perspective, from the Operating Systems your users land on to the applications they consume. It’s about finding what’s right for your business needs.

An overview of the benchmarks available can be found here

and here is that list filtered on Operating Systems then Microsoft Windows

Finally, here is the above list filtered on Desktop Software then Web Browser

As you can see there are lots of options available to you, and It’s really down to you how far you wish to dive into this rabbit hole.

CIS Levels

The CIS benchmarks are broken down into 2 levels (1 and 2) designed to give you the flexibility to secure parts, or all of your environment to the different security requirements of your business.

The details of what the levels cover is shown in the table below.

End User Computing and CIS Risk

Reading the above you probably think, great, we can just put all these Level 1 CIS policies in and we are secure.

Not the case, This is (as with everything security related) just one tool in your belt, but, it will help.

There is also the risk of failure. Some of the settings you will define in your base policies are intrusive and can break End User Computing environments very quickly so make sure you TEST, TEST and TEST again before putting these into production. That said, once you have everything defined and tested it does give you a good policy set for security in your environment that’s easy(ish) to manage.

CIS Hardened Images

What if you are running operating systems in the Public Cloud. Well thankfully rather than applying a bunch of GPO’s to them and breaking something fundamental, most of the providers have given you access to CIS Hardened Images available directly from them. To find a list of these look here

These gives you a great starting point for deploying a secure image straight from your Cloud Provider and testing from there.

Secure By Design - CIS Group Policy Layout

This is important to understand before you begin actually configuring and new CIS Group Policies as understanding this will provide you a really easy way to manage your policies over time and will also allow you to be very granular in how you apply your exceptions.

Let’s look at a typical Organizational Unit layout for a Citrix Cloud DaaS deployment

Now if we look at how CIS is generally deployed (using Server OS as an example) you will see the following

• MemberServer_2022_CIS_Policy_Exceptions_v1
• MemberServer_2022_CIS_Preference_Exceptions_v1
• MemberServer_2022_CIS_Policy_Level1_v1
• MemberServer_2022_CIS_Preference_Level1_v1

So, looking at the above list (they will apply bottom up) you can see that CIS Level 1 Preferences and Policies will apply first. These will have ALL the recommended CIS settings configured should they break the platform or not (read note below for reasoning).

The 2 GPO’s above that for Preference and Policy Exceptions will specifically unpick and CIS setting that breaks your environment and/or will be added to the default CIS policy for specific business needs.

The reason for putting ALL the CIS configuration into the base policy is that you are trying to design secure by default. If one of these settings breaks something then you will have to justify that back to the business and get them to accept the risk of undoing a secure setting. Along with this it will not break ALL the servers, only those that use that specific setting. This way you can have a secure baseline GPO applied across your estate and only unpick security where it is absolutely necessary

Another point worth mentioning is that generally the CIS Baseline GPO’s are filtered against the specific Operating System or role they are targeting. This means you can have the baseline GPO’s assigned at a higher level in your Active Directory giving you a broader security posture and be sure that they will apply only to those operating systems specifically targeted.

With that in mind let’s have a look at how we could potentially lay out CIS GPO’s for the above OU structure

Looking at the inheritance on the Cloud Connectors for example

You can see that ALL the default security settings are applied then we apply the Global Exceptions we have deemed fit for any domain joined machine, then finally just the exceptions for the Cloud Connectors

This is a good win as you are securing everything by default then only unpicking what’s required to make your platform component work.

Building CIS Policies

This is that time-consuming part, believe me, I have done this before.

The first thing you want to do is head over to the CIS WorkBench and register for a free account here. Once you have that set up and logged in you will see all the available benchmarks available.

Filter the list using the search box

Then click on the benchmark you wish to view

On the left you can see a tree view of every setting that’s defined in the benchmark (yes, there are loads!) but from here you can drill down and start to configure these in Group Policy

The benchmark setting will normally give you the Group Policy location for the setting as well as the registry path, so you can use GPO or another tool to configure these.

This is the part that will take the time as you will have a ton of settings to configure, but it will give you a good secure baseline for your images that (once configured) can easily be applied to other servers in your estate.

Once you have your baseline settings done go ahead and set up your exception policies for each of your relevant OU’s and bind them as shown above, reboot the machines and get testing.

What About Apps

All I have talked about so far is Server and Client Operating Systems, what about the apps that our users run.

The same approach can be taken with those in that you define your secure baseline then add exceptions to suit your business needs over the top. This will go along with the Secure By Design reasoning and provide you with a solid, manageable set of policies in the long term.

You will be able to find benchmarks for most of the common applications your users consume in the same location linked to above.

The Easy (But Expensive) Path

The above is pretty straight forward from a configuration perspective, but IT TAKES TIME to get up and running.

There is an easier way but it is expensive. That said, what price would your company pay to be secure compared to the cost of a breach, if you compare the 2 It’s not really too much to ask!

If you join the CIS Secure Suite here you can download the base configurations already configured that you can just import into your existing GPO infrastructure then all you have to do is define the exceptions, and you are good to go!

Told you, easy but not cheap!

Conclusion

In conclusion, do I think its worth the investment in time, YES!

This will take a long time to set up, test and get into production but the advantage it will give you from a security standpoint cannot be underestimated.

There are people out there that want to damage your infrastructure, as an owner of an EUC environment you are already a target. For the sake of spending some time setting up Group Policy at no cost, why would you not do it.

Overview

I presented at the UK Citrix User Group recently on 10 Quick Wins for Red Team Testing and one of the subjects I covered was hiding base applications from the users when they do not need access to them.

Now, I know there are a host of tools to do this and that some are better than others (think application whitelisting) but what if there was a quick win? One that may not stop all attacks but will prevent the majority of internal users (yes, not all attacks are external) from even seeing PowerShell, Ping, FTP and a whole host of applications even being installed on your platform.

Enter FSLogix, specifically FSLogix App Masking.

When many hear FSLogix, they immediately think “ahh, yeah the profile tool” but there is another tool in your arsenal, Application Masking.

This post is not intended to give you an “all-in” look at App Masking and what it can do, if you want that then look here but what this will do is show you how to hide common apps that are not required from your standard users to enable a more secure platform.

What Is App Masking?

According to Microsoft Application Masking manages access to an application, font, printer, or other items. Access can be controlled by user, IP Address range, and other criteria. Application Masking significantly decreases the complexity of managing large numbers of gold images.

Normally this is what it is used for, a group of users “Word Users” for example get access to the installed copy of Word. If you are not in that group then FSLogix App Masking “hides” that application. That’s it, gone, like It’s not even installed.

I am not going to claim to be clever enough to understand how all of this works under the hood, but, if we applied the same principle to a master image then we could in theory “hide” system applications we don’t want users to have access to but leave them there for the Administrators. This can be done at image creation or even applied to an existing image making retro fitting this easy!

Installation

The first thing you will want to do is install the FSLogix product set onto your master image. You can download FSLogix from here and just extract the ZIP file onto your master image.

FSLogix Apps

Run the FSLogixAppsSetup.exe file

Click to agree to the licensing and click install

FSLogix Apps Rule Editor

Run the FSLogixAppsRuleEditorSetup.exe file

Click to agree to the licensing and click install

I normally install the Rule Editor onto the master image in order to be able to select files, folders and registry keys from the platform that the users will be operating from. You can remove this if required once the rules are set up

Rule Configuration

Once the software is installed on your master image open up FSLogix Apps RuleEditor from the Start Menu

Click on New to create a new rule and save it to a location you can copy the 2 files from later (in my case I am putting it on the desktop)

You will notice 2 files get created, you will need both of these to implement the rule later. One is the rule definition and the other is the assignments.

Select to create a Blank Rule Set and click OK

Right click in the right-hand pain and select New Rule

Select Hiding Rule and click Browse

Select to browse for a file

Locate the PowerShell executable from the pop-up window that appears

Click OK and select Yes to the system instability warning

Repeat this process for all the programs you want to hide from your users. Below are the programs and printers that I normally add

Hiding Rules I Add

Hiding Rules As Per Microsoft

Now, Microsoft have been kind enough to provide a list of applications that attackers could potentially use to bypass AppLocker or Windows Defender Application Control. You can find this list below

https://learn.microsoft.com/nb-no/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules

This is their take on it

Members of the security community* continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass WDAC.

With that in mind I tend to add the relevant applications provided by Microsoft to by rule set to prevent internal users accessing these.

Please note that EACH ENVIRONMENT DIFFERS, you will have to test this prior to releasing it into production, or you could break lots of your VDA’s. Check on each exe file and see if it is feasible to implement in your environment. Test, test and test some more and if you don’t, well, that’s your own fault then!

Once you are done you should have a fairly robust rule base as you can see below

Next you will need to deal with the assignments, this is who this rule applies to, and also who it does not!

Click on Manage Assignments and remove Everyone from the list. Then add Domain Users and select Rule set does apply to user/group and also add BUILTIN\Administrators and select Rule set does not apply to user/group

Click to save the rule and close the rule editor.

Deployment

To deploy your new rule you will need to copy both files to the following location on all your VDA’s

This can be done with a start-up script, part of the image seal process or a whole host of other options, that’s up to you.

Testing

First let’s test as an Administrator to make sure that everything still works as expected

As you can see PowerShell still works

As does ping

So, let’s switch to a standard user

You can see that Windows can’t even see that a registry editor is installed now, if you try and run it, nothing happens

The same with Windows PowerShell

So, let’s try and run the PowerShell file directly from the file system

As you can see, it’s not there, FSLogix App Masking is doing its job and “masking” those files we defined earlier from the user.

Conclusion

Now I know that there are plenty of smart people out there who may be able to bypass this with all the tools they have available to them. But, if you consider that quite a bit of breakout is done internally by your standard users this is a pretty good win.

It does not take a lot to set up, does not cost much and can immediately add a layer of security between your users and the base operating system you are deploying to them.

Overview

Is your Citrix Platform Secure? Did you inherit your platform and have just built on what’s there policy wise to suit the business needs? If so, maybe it’s time to take a look at what you have policy wise and what your users can actually do!

Citrix Policy by default is NOT secure, your platform will be left open and attackers WILL take advantage of this. This is done to make life easy for the installers of the platform and will make it extremely user-friendly, but, you should understand what this means for you and your business.

Default Citrix Policies

So, let’s have a look at what Citrix will give you out of the box. This is with a default install of the product on-premises or in the cloud.

The Issue

As you can see from the above, if you have left your Citrix policy as default you are setting yourself up for a world of pain down the line. Some of the examples that you could be left open to are:

• Attackers can copy and paste all data out of the session
• Attackers can drag and drop files into and out of the Citrix session
• Attackers can insert USB drives and then copy data to them
• Attackers can print out any data they desire from your platform
• Attackers can screenshot their session then take that data elsewhere

This is obviously an issue and should be addressed. Read on…

The Solution

BE SECURE BY DEFAULT, really that’s it. Set up a secure policy by default and grant additional access by exception.

Now I realize that this is not always easy and can often be met with a bunch of challenges (I had to personally fight for nearly a year to block copy and paste as it “stopped” the business working fast apparently) but its one way you can get a handle on your environment and really know what your users can and cannot do.

The Policy

Citrix have provided you with an excellent starting point for a secure by default policy.

If you log into Citrix Cloud (same for on-premises) and navigate to the Policies section

Then click on Templates

You will see a template called Security and Control

Click on that and then click on Create policy from template

Click on next accepting the Template default settings

Assign it to All objects in the site

Give the new template a name and a description

Click on Finish and you will have your new template ready to edit.

So, that’s a great baseline. Now click on that template and select edit and update the settings to INCLUDE the following settings. Each section has been divided up into its own table to help filter them out if you don’t want all the settings.

SOME OF THESE ARE SET BY DEFAULT, however, I prefer to set them manually in case Citrix decide to change their default stance on policy settings. It means you don’t have to trawl the policy updates each release to ensure you are still secure

File Redirection

Local App Access

Port Redirection

Printing

Security

Make sure you update your Delivery Groups to reflect this

Session Watermark

USB Devices

Once you have set all these up save and close the policy. Enable it and set this as the default for your platform, and you will have closed a bunch of security risks with a single policy.

Enabling Exceptions

Once your baseline policy is in place you can create separate policies for enabling the clipboard for example or enabling printing and then rank them higher and filter them on groups. This will enable you to add access by exception rather than by default.

Filtering

To set up access over and above your default secure settings you will need to use filtering. Below are some of the filters I use the most and a brief reason why, these are by no means a comprehensive list of what you can achieve but may provide a good starting point.

User or Group

This is the most common to be honest. You can assign a policy such as Enable Clipboard to a specific set of users in your domain. Quick note on this though, if possible control the group admin to a VERY SPECIFIC group of people using ACL’s. These groups grow fast!

Client IP Address

This one is useful if you want to allow certain policies to internal users only but not to external users. Simply add your internal networks to this then boom, you’re done, all internal users can now copy and paste or copy files in and out but external users cannot. This is assuming you have sufficient building security and that the ONLY devices on your internal network are trusted and managed.

Access Control

I have used this one LOADS and it is so useful. If you are licensed and have a NetScaler for external access you can enable EPA and based on the result of that scan, apply applicable policies.

For example, a user can log in externally from their corporate laptop, pass the EPA and as the device is managed and trusted you can enable Copy and Paste. However, if that same user logs on from their own device, EPA will fail and the Copy and Paste policy will not apply. Same user, different device and context and therefore different policy. Super powerful!

Conclusion

Citrix Policy is powerful! You should 100% take a look at your policies you have in place right now and check with your SecOps teams to ensure that your users cannot do things you would not want them to. Trust me, your Citrix environment is one of the first things they will go after and if your policy is not set right, it’s a quick win for the attackers!

Overview

I have often needed information from my Nutanix Clusters that I can use for a report or just programmatically and always use the API that Nutanix has to get this data.

The reason for this is that it allows me to get the information I want into a variable and then manipulate it with PowerShell to give people (often management) exactly the information that they require.

Fortunately Nutanix have great documentation of their API and you can find that here.

For this code I am using the v3 Prism Central API. Why? Well from Prism Central you can get information about any of the clusters that you have in your organization (think VMware vCenter) and pull that back for use in the remainder of your script.

I have written the code so that you are able to pass in the:

• API Root Version
• API End Point
• Method
• Payload

So, you should be able to get pretty much any information you want from Prism Central just using this code. All you have to do is check the documentation and find out what the above variables need, as can be seen in the image below.

As Nutanix change the API versions you should be able to update your code to the new version by just changing the API variable you pass in.

I would recommend putting this code inside a function and passing in the parameters, therefore making the code reusable, but this is just an example of the code that you can use to get the information that you require.

Variable Descriptions

PowerShell Code

Below you will find the PowerShell code used to query the Prism Central API

# Define Variables
$IP = "192.168.100.10"
$UserName = "admin"
$Password = "SuperSecretPassword"
$ApiRoot = "api/nutanix/v3"
$API = "subnets/list"
$Method = "POST"
$Payload = "{ }"

# Build Credential Object
$credPair = "$($UserName):$($Password)"
$encodedCredentials = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($credPair))
$headers = @{ Authorization = "Basic $encodedCredentials" }

# Build Connection Uri
$URL = "https://$($IP):9440/$($ApiRoot)/$API"

try {
    $ApiResult = Invoke-RestMethod -Uri $URL -method $Method -ContentType 'application/json' -SkipCertificateCheck -Headers $headers -Body $Payload
}
catch {
    Write-Error "Error Executing RestAPI Call"
    Exit
}

Example

Get List Of Subnets

Conclusion

I have found this small code snippet super useful when I am getting information back from my Nutanix Cluster. It allows me to call this code within a function and just pass in the API end point that I want to query as well as a Payload and Method and pull those results directly back into PowerShell

Overview

In a multi-user environment you often have several applications installed on a single Windows system and either publish applications to the user or grant them access to a desktop hiding various items from the start menu. Whilst on the surface this may seem sufficient to stop your users accessing things they should not, I have seen attackers use the File Open dialogue to access applications on a server that they should otherwise not have access to.

The problem here is that if you do not have a load of master images and want that single image nirvana then you need a way to lock apps to only the users that you deem necessary as you will often have ALL the apps installed on the same, single master image.

There are a ton of ways to do this, and if it were me I would probably use 1, if not all of them, however for the purpose of this post I am going to show you one step in that process:

Hide the “Right Click, Open With” dialogue

The Security Issue

First let me show you what this specific issue is meant to defend against.

If we log into a Windows 11 machine and open up File Explorer you can see we have 2 files there

Now if we right-click on the Text Document and select Open With we get the option to “Choose another app”

Clicking this displays a list of all the applications associated with that file extension, from here we can click on “Choose another app on your PC”

This will open up a File dialogue and allow us to browse the local drive for any application we deem fit.

Please note that you should have your Local Drives locked down, if you want help doing this please read my article on doing so.

So if we now go ahead and open up the text document using Excel

Then, once open use the Excel search bar to look for “Macros”

Give the Macro a name in the pop-up dialogue and click on Create

This will give you access to the Visual Basic editor and allow you to write and execute any code you wish, all from opening up a text document.

Registry Fix

Luckily there is a relatively quick fix for this but in my opinion It’s not so elegant.

Open up the registry editor

Then navigate to the following key

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers

Locate the Open With Key and delete it

Next time you try and use the right click open with dialogue you will see its gone!

FSLogix To The Rescue

The above method is good, and it works, however, what if:

• As an Administrator you still want the functionality
• You “forget” to implement the fix on a single VDA

This will leave you open to attack and not be something you want.

Let’s have a look at how FSLogix can help.

History

FSLogix was bought by Microsoft and It’s pretty much available now to everyone who is using Virtual Desktops. Whilst this is great and a big win for profiles there is another component to FSLogix that can help us here, its called “App Masking”

This gives us the ability to hide applications, files and registry keys based on group membership. With this in mind we can hide the right click open with key from all users except the Administrators. This means that as an Admin you can still use the functionality but if you are a regular user (as I hope your users are!) you won’t see the key as its masked.

To learn more about installing FSLogix click here

FSLogix Fix

Start by opening the FSLogix Rule Editor from one of your VDA’s

Select a location to save the new rule set

Select the option for a “Blank Rule Set”

Right click in the pane to the right and select “New Rule”

Select “Hiding Rule” from the drop-down and click Browse

Select “Registry Key”

Browse to the following registry key

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers

Select OK and accept any changes that FSLogix Apps Masking suggests

Click Manage Assignments

Select to “Rule set does apply to user/group” for Everyone and add Administrators as a group, selecting “Rule set does not apply to user/group”.

Save and copy the FSLogix rules according to the installation guide for FSLogix above and test as a regular user.

You will see that FSLogix is “Masking” the registry key from the user and therefore not showing it.

Conclusion

This is a quick win and a simple one to implement. As with everything like this is it not foolproof and also is not a complete win-win, but it will help to go some way down the path to securing your VDA’s and stopping your users getting access to things they should not have access to.

Overview

Continuing down the ethical hacking journey I was recently asked to provide a geographical security baseline to a Citrix NetScaler setup. The request was something flexible enough to provide security quickly and easily but also something that was simple to manage.

I have known about using the Geo IP Database on Citrix NetScalers for a while but when I was asked about this there were a couple of requests.

• Have the ability to globally lock out certain regions from ANY service that resides on the ADC
• Have a more granular control of specific services that are running on the ADC
• Have the ability to quickly lock out a region from accessing ALL or INDIVIDUAL services immediately

The rest of this post will address how to achieve this on a Citrix NetScaler as well as walking you through configuring this for use within your own environment.

If licensed I would put this in as a default setting even with ALL regions allowed. This means that the framework would already be in place for you to quickly and easily lock out regions should your security team request it from you.

First lets cover off the technologies we will be using to achieve this:

Geo IP Database Citrix Application Firewall Citrix Gateway and Responder Policies Geo IP Database I will start with this as this is fundamental to the remaining policies working correctly.

Geo IP Database

Navigate to AppExpert -> Location -> Static Databases and click Add

Then navigate to /var/netscaler/inbuilt_db

Here you will see the in build Geo IP Databases included with Citrix NetScaler, you can go ahead and select the relevant one and click Open

You will now see that your Geo IP Database is there and (almost) ready to use

If you are using a firmware version after 11.1 Build 53.11 you will need to enable wildcard search. Open up a putty session to your ADC and enter the following command

set locationParameter -matchWildcardtoany YES

So now you are ready to test that your Geo IP database is imported correctly and working as expected.

From the putty session type the following

show locationparameter

Here you can see the Wildcard qualifier is all set up and the Geo IP database is ready to go. Let’s just test that it’s getting the right data back from the database.

Type in the following then enter any public IP (I am using my public IP my ISP has assigned me)

shell
nsmap -d –t

Here you can see the NetScaler knows that I am in Europe, I am in Great Britain and in England.

Great, that’s the Geo IP Database installed and working, lets move onto locking your NetScaler down.

Citrix Application Firewall

First thing I want to do is lock down access globally to all but the 2 regions that the business operates from. In this case its:

• United Kingdom
• United States of America

Access from ALL other regions will need to be blocked, however, I want to have the ability to easily onboard another location should the need arise.

Before I get into this I want to point out an invaluable resource. It’s called the ISO 3166 Country Codes, and it has ALL the country codes that the Geo IP database is built on. You can find it here

So, looking into this I can see that I want to allow access from the following 2 codes.

• US for United Stated
• GB for United Kingdom.

Head over to Security -> Citrix Web App Firewall -> Policies -> Firewall and click on Add

Give your new profile a name and select the built-in APPFW_DROP profile. In the expression you want to put the following

CLIENT.IP.SRC.MATCHES_LOCATION("*.GB.*.*.*.*").NOT && CLIENT.IP.SRC.MATCHES_LOCATION("*.US.*.*.*.*").NOT

What this does is; block ALL traffic except GB and US public IP’s. You may think there should be an OR statement here (so did I) but trial and error showed that you need the and (&&) to make both work.

Click OK and create your new policy

Then click on the policy manager button at the top of the page

Click to continue through override global

Click on Add Binding and select your new policy from the list provided

Click on Done and that’s it. You have just blocked all traffic to your NetScaler except GB and US traffic. Go ahead and try getting to your Citrix Gateway – It should still work fine.

So for the purpose of testing this I am going to remove the GB expression and retest to ensure that my traffic is blocked

There it is. Blocked.

So you now have the ability to easily block or allow FULL NetScaler access to any region, just update the app firewall expression, and you are good to go.

Citrix Gateway and Responder Policies

We have access to the NetScaler from the US and GB regions, but we have been asked to lock down the Citrix Gateway to ONLY be accessed via the GB region as the US use other Virtual Servers on the NetScaler and not the gateway.

We can achieve this via Responder policies. But first let’s think of the error page.

I know this sounds weird but when we block via Responder we are going to want to display a nice page stating they are denied access rather than a “Page Cannot Be Displayed”

Head over to AppExpert -> Responder -> HTML Page Imports and click add to create a new HTML Page.

You cannot put links to images in your page here, if you want to put an image in your HTML page you will need to convert the image to a Base64 string first and reference that in the HTML. This can take a bit of time to get right but stick with it until you get this right – your users will appreciate the effort you put in!

Here is my error page HTML and below what it looks like for real

You have your HTML error page done, now head over to AppExpert -> Responder -> Actions and click new to create an action. Give the action a name, select Respond With HTML and select your new HTML page from the list

Click ok then head over to AppExpert -> Responder -> Policies and click Add to create a new Policy. Give your policy a name, select your new Action and put the following into the expression

CLIENT.IP.SRC.MATCHES_LOCATION("*.GB.*.*.*.*").NOT

This states that you want to display your error page to ALL traffic except from the GB region. Remember the App Firewall policies earlier. In essence ONLY US and GB traffic can get through, but ONLY GB traffic can access the gateway

Click ok then bind this new policy to your Citrix Gateway as a REQUEST type.

Let’s test – first try the gateway from my machine here in the UK

Works fine – now to test from the US. Thanks here to my buddy Jarian Gibson for testing this.

There we go.

Conclusion

So we have locked down global access to our NetScaler using Citrix App Firewall and specific access to our Gateways using Responder.

We can quickly lock out regions globally by removing them from the App Firewall Policy or grant new regions by adding them. Finally, we can edit specific access to the Citrix Gateways by editing the responder policies assigned.

Hope this gives you a quick insight into how you can use Geo IP and NetScaler to secure your remote access by region.

Overview

This is another lesson I have learned from a recent “Ethical Hack” – lateral movement can get you in trouble fast! First let’s take a look at what lateral movement is.

In essence, it means moving sideways or to the side. In terms of an attack on your EUC platform it can have devastating consequences and really fast.

What an attacker will do is get a foothold in your network, and this can be anywhere. Take note of this as its important – it can be in another part of your organization that you do not own! Think “Domain Admins” – then move sideways (or laterally) around your network and into your EUC stack, from the inside.

This is clearly an issue and one that needs addressing as best you can whilst still maintaining usability and administration ability of your platform.

As with anything when dealing with security – it’s a long road. This article is again, just a starting point, but one that should give you some control of who and what can access your EUC environment.

Please note, whilst I am going to use Citrix Virtual Apps and Desktops in this post as an example, these principles apply to ALL EUC platforms. Just break the platform down into individual components and go from there.

Secure Lateral Movement

Administrator Groups

I am going to start out with a “Simple” environment and then go into how I would minimize lateral movement around that platform.

As you can see from the above we have the following components in our environment:

• Hypervisor
• Citrix NetScalers
• StoreFront
• Director
• Licensing
• Controllers
• FAS
• VDA’s

Now, one of the issues that I see a lot is the good old “Citrix Admins” group. This is the group that you create right at the start of the project to configure your initial site and this gets “inherited” from there on out. At best, I normally see NetScaler, Hypervisor and Citrix Admins.

The problem with this is illustrated below

The red lines above illustrate what an admin enabled user can get to in the event that they can glean those all important credentials. This would be the scope of their lateral movement around your platform only, this does not take into account where they can go from there once they get that foothold.

Now there are hundreds of ways to minimize this risk, but I want to start small, so with that in mind, the below is what we are trying to achieve and with GPO and Group Design only.

So how to we achieve this. First we can create groups FOR EACH COMPONENT of the platform. not an overall admin group for the platform as a whole. This will mean a little more group admin in the long run, but it will allow you more security on your platform.

Next we will set up a good OU structure to be able to apply the Group Policy to in order to achieve the desired lock down.

You may notice that NetScaler is not listed above – this is because the way we apply restricted admins to the NetScaler is not via GPO but with an auth policy on the NetScaler itself.

Finally, create a new Group Policy Object and link it to the top level OU for your platform.

So – lets start to build out the Group Policy to restrict access to the components of our estate.

Direct Access Users

What’s this? Well this is a group that you will need to be in if you are NOT an administrator to be able to remote desktop to the server via a non-brokered connection.

Users DO NOT need to be in this group if they connect to the VDA via Citrix StoreFront and Virtual Apps and Desktops as this is a brokered connection. However – if they want to connect to the server directly over RDP they will need to be an Administrator or a member of this group.

For this reason, I like to lock this group down and ensure that it is empty.

Edit your new GPO and go to Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups

Right click and select New -> Local Group

Select Replace, name the group “Direct Access Users” and select to remove all users and groups from this local group

That’s Direct Access Users taken care of, so lets move on with the rest of the platform.

Group Policy

We will deal with StoreFront initially. Right Click and create a new Local Group. Select “Replace” for the action, pick “Administrators (built-in) as the Group Name. Tick the box “Delete all member groups” and add your new StoreFront group to the Members section.

Click on Apply then select the “Common” tab at the top, put a tick in “Item Level Targeting” and select the Targeting button

Select “New Item” then select “Organizational Unit” from the drop-down

When the search box pops up locate the OU that you will be putting your StoreFront servers in and click OK

Click on Apply then OK.

Repeat this task for ALL of your EUC components only selecting the different group name and different OU in the item level targeting. Once done you will end up with a seperate Administrators group for each of your components but filtered on the specific OU.

There are certain components that will require additional groups in the local Administrators (StoreFront Configuration Replication etc), make sure to add these as well as your new custom group.

So, now you can go and test that this part is applying correctly. Log into your StoreFront server and refresh group policy using gpupdate /force (make sure you have added your account to the NEW admin group!)

As you can see the Administrators group now only has the LOCAL Administrator account (I will deal with managing this account in a later post) and your new Admin group. We can also know that the “Direct Access Users” group is empty as we are enforcing that via GPO.

Why No Domain Admins?

Well, like I said earlier in this article, this is about lateral movement around your estate and this includes way more that your EUC environment. You likely have a whole host of other infrastructure in your environment and how can you be sure that they are all as secure as you are “trying” to be.

I remove “Domain Admins” so that is someone manages to get into that group somewhere else in the environment then that doesn’t necessarily make them an admin on the EUC platform.

I am sure that there are ways to circumvent this but like I said at the start, this is meant to be a starting point!

What about “Other” Groups?

This is true, there are other groups on your infrastructure that will give a user more than normal rights to the server. I also tend to strip these out via Group Policy unless specifically required.

Do the same as you did for “Direct Access Users” for:

• Backup Operators
• Power Users
• Device Owners
• Hypervisor and NetScaler

Make sure you secure these also by adding your new group to the Hypervisor Administrators and also creating a LDAPS Filtered policy for Administrator access to the Citrix ADC’s (link below)

https://support.citrix.com/article/CTX212422

Group Security

Once all this is set up, and you have validated the group members I would highly recommend locking down the ability to add and remove users from your new admin groups and pull changes to these under a change control process. I have used Change Auditor for this in the past, and it works great!

Conclusion

So, with this in mind we should have gone some way in preventing lateral movement across your EUC platform by ensuring that users need to be specific admins for specific components and preventing the overall “Citrix Admins” group.

Hope this helped some of you out.

Overview

Securing local drive access in an End User Computing environment is essential to ensure that your users do not gain access to applications and tools that they are not entitled to. The purpose of this article is to show you how to lock down that access so that you can be sure your endpoints are secure.

Standard Drive Lock Down

This is fairly simple and a quick one to implement – it’s a simple GPO settings that I’m sure most of you already have in play today.

Go ahead and create a new Group Policy Object and link it to your VDA’s. First thing you are going to want to do is disable this applying to the “VDA Administrators” Group as you will want to be able to access the local drives as an admin.

Click on the GPO -> Delegation then click the Advanced button. Add your VDA Admin group in there and select “Deny” to apply the group policy. That’s it – this will not apply to your Administrators now.

Next open up the new GPO and go to User Configuration -> Policies -> Administrative Templates -> WIndows Components -> File Explorer. Open up the setting for “Hide these specified drives in My Computer” and Enable that setting with the specific drives

Click on OK then open up the setting “Prevent access to drives from My Computer”, enable that and set the same drives as you did in the previous setting

That’s it! Stage one is done – simple right? Be assured though that we still have a long way to go.

Jump onto a VDA and refresh group policy using gpupdate /force and check that the drives have been disabled.

NOTE: If this policy is not working as expected make sure you have Loopback processing turned on for the OU that the VDA’s reside in.

As you can see here – no local drives. Happy days. However, in the address bar type in \\localhost\c$ and see what it does…

UNC Paths and the Pitfalls

There it is – your back into the C Drive. So not we need to go about locking this down and closing it out for the users.

Open up your GPO and go to User Configuration -> Policies -> Administrative Templates -> Start Menu and Taskbar. Then open up the “Remove Run menu from Start Menu” setting and enable it

Log out and back into your VDA to apply the policy and retest getting to \\localhost\c$

There you go – another door closed. However, this is a pretty brutal way of doing this as there are legitimate business reasons you would want to enable UNC paths, for example, what if you want to allow access to a “real” network path via the explorer menu bar?

That’s also disabled and this is a pretty poor user experience. So this is the pitfall in my opinion of enabling this setting. Go ahead and set that back to “Not Configured” and we can try to approach this a different way

Loopback Execute Rights

Lets approach this a different way. Open up the GPO and go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Application Control Policies -> Applocker -> Executable Rules.

Make sure you have created the default rules to allow Windows to operate then right click and create a new rule. Click next and select “Deny” for everyone

Click next and select “Path

Click next again and in the path put \\localhost\*

Click on Create.

Then do exactly the same again but instead of localhost for the path enter \\127.0.0.1\*

Once done you should have 2 new rules created in your GPO to Deny access to applications launched from the localhost and loopback addresses

So let’s test it out. Jump back onto your VDA and update the group policy. Open up explorer and get to the loopback address for localhost and try to start an application up

As you can see the ability to run applications from the localhost locally has been disabled, let’s try this using the loopback address to make sure that this is also disabled as expected

Perfect – so your users can now no longer run applications if they use localhost or loopback. Let’s just make sure that UNC paths still work for valid network shared via explorer

Great – so we now have the drives locked and also the loopback addresses locked down.

Google Chrome

Why on earth am I writing about Google Chrome in an article that deals with Local Drive Access?

Well, one of the first things that “Ethical Hackers” will do is open up Google Chrome and type in C: in the address bar

There you have it – all that good work undone in 2 seconds with Chrome.

Open up your GPO and make sure you have added the Google Chrome ADMX templates. Navigate to Computer Configuration -> Policies -> Administrative Templates -> Google Chrome and open up the setting “Block access to a list of URL’s”. Enable that and click the “Show” button to add the URL’s

Add the URL (copied directly from Chrome in your VDA) to the list and be sure to add any others you want to restrict access to

OK and apply that and then test again by logging out and back into your VDA

Excellent – that’s closed. Now let’s try to localhost and loopback and make sure you can’t get to then via Chrome

Damn, same problem as before. Open up your GPO and add the Chrome Loopback into the URL restriction list

Then jump back onto the VDA, refresh GPO and retest

OK, so it’s not worked. Looking in the registry you can see that the policy has applied to the VDA

In short, this was something that I could not block using the Chrome URL Blacklist. I am not sure why it’s not working as local drives work fine but the loopback address and localhost would always allow to be to get to the local drives.

Time for another approach!

Admin Shares

So, the reason for logged-in users being able to access loopback and localhost is that the administrative shares default behavior was changed when moving from Windows Server 2003 to 2008. The change that was made was to allow the “Active Logon Account” access to all the administrative shares.

This is what is causing us our issues as any user on the VDA is essentially an “Active Logged On User” and can therefore access all the admin shares. Not good for us!

There is a fix for this detailed below, but first…

Please TEST this in development FIRST as this may affect some of your admin tools accessing the VDA. I have not personally seen anything break when applying this but TEST before you put it into production. I don’t accept responsibility etc etc

This does require a reboot so if you are using non-persistent devices you will need this in your master image.

[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

Once the VDA has booted log back in and test getting to your loopback address using Chrome

You can also test with \localhost

What you will also notice is that if you try to access the loopback address now as a normal user you will be prompted for admin credentials, so another win there.

Conclusion

So there you have it, my take on how to lock down local drive access in your EUC estate.

Hope some of you found this useful.