Securing a Citrix ADC (formally known as NetScaler VPX) to score an A rating on Security Headers - March 2020

Continuing from my previous post for securing the Citrix ADC to score an A+ via Qualys’ scan:

Securing Citrix ADC (formerly known as NetScaler VPX) to score A+ rating on SSL Labs - February 2020

http://terenceluk.blogspot.com/2020/02/securing-citrix-netscaler-vpx-to-score.html

… I would like to demonstrate how to score an A on the Security Headers (http://securityheaders.com/) scan.

***Before I begin, note that I am scoring an A and not A+ because I have yet to determine how to configure the Content-Security-Policy without two directives that caps the score at an A without breaking the logon portal. I will update this post in the future when I am able to determine how to get around it.

Without any additional configuration, a newly published Virtual Server for Citrix Virtual Apps Desktops published by a Citrix ADC with the configuration in my previous post typically scores a C or lower:

… with the following headers that are identified as to be missing and need to be addressed:

Content-Security-Policy - https://scotthelme.co.uk/content-security-policy-an-introduction/

Referrer-Policy - https://scotthelme.co.uk/a-new-security-header-referrer-policy/

Feature-Policy - https://scotthelme.co.uk/a-new-security-header-feature-policy/

The steps to remediate these issues are to create new Rewrite Actions to insert the headers, bound them to Rewrite Policies, and finally to bound them to the appropriate internet facing virtual server. I will demonstrate this with the same Citrix Gateway Virtual Server I used in the Qualys example:

**Note that the configuration for each Security Header in the examples below can and should be customized based on the requirements of the published virtual server. Please review the links I included above for each header and ensure that you understand the options and what they are used for so you can better tweak the rewrite action parameters.

Adding the Content-Security-Policy header

The rewrite action I will be using for the Content-Security-Policy header will be as follows:

add rewrite action rw_act_insert_Content_Security_Policy insert_http_header Content-Security-Policy "\"default-src \'self\' ; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' ; style-src \'self\' \'unsafe-inline\' \'unsafe-eval\'; img-src \'self\' data:\""

"default-src 'self' ; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; style-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:"

**Note that if you remove the directives 'unsafe-inline' 'unsafe-eval' you can score an A+ from the scan but it also renders the Citrix portal unable to load.

The rewrite policy I will be binding the rewrite action will be as follows:

add rewrite policy rw_pol_insert_Content_Security_Policy "HTTP.RES.HEADER(\"Content-Security-Policy\").EXISTS.NOT" rw_act_insert_Content_Security_Policy

HTTP.RES.HEADER("Content-Security-Policy").EXISTS.NOT

The last step to bind the rewrite policy to the virtual server will look as such:

bind lb vserver <virtual server> -policy rw_pol_insert_Content_Security_Policy -type RESPONSE -priority 130 -gotoPriorityExpression NEXT

Note the Rewrite Policy under the Response Policies heading:

Be aware of the following configuration in the screenshot above:

Priority – The value will be dependent on what other rewrite policies are currently configured for this VPN Virtual Server.

GOTO Expression – Note that I have configured this value to NEXT instead of END because I will be adding more Rewrite actions that will have a lower priority (higher Priority number) this this VPN Virtual Server and if I configure the value as END then the rest will not be applied.

Executing the Security Headers scan should not find the Content-Security-Policy header present:

One of the issues I’ve encountered when inserting this header into a portal integrated with a DUO MFA solution was that it was no longer able to redirect my login requests to the 2FA page. If you encounter such an issue then please refer to one of my previous posts here:

Configuring Content-Security-Policy HTTP Response Header on Citrix ADC for Citrix Apps and Desktops with DUO integration

http://terenceluk.blogspot.com/2020/02/configuring-content-security-policy.html

Adding the Referrer-Policy header

The rewrite action I will be using for the Referrer-Policy header will be as follows:

add rewrite action rw_act_insert_Referrer_Policy insert_http_header Referrer-Policy "\"strict-origin-when-cross-origin\""

"strict-origin-when-cross-origin"

The rewrite policy I will be binding the rewrite action will be as follows:

add rewrite policy rw_pol_insert_Referrer_Policy "HTTP.RES.HEADER(\"Referrer-Policy\").EXISTS.NOT" rw_act_insert_Referrer_Policy

HTTP.RES.HEADER("Referrer-Policy").EXISTS.NOT

The last step to bind the rewrite policy to the virtual server will look as such:

bind lb vserver <virtual server> -policyName rw_pol_insert_Referrer_Policy -type RESPONSE -priority 140 -gotoPriorityExpression NEXT

As with the previous rewrite policy, be aware of the following configuration in the screenshot above:

Priority – The value will be dependent on what other rewrite policies are currently configured for this VPN Virtual Server.

GOTO Expression – Note that I have configured this value to NEXT instead of END because I will be adding more Rewrite actions that will have a lower priority (higher Priority number) this this VPN Virtual Server and if I configure the value as END then the rest will not be applied.

Adding the Feature-Policy header

The rewrite action I will be using for the Content-Security-Policy header will be as follows:

add rewrite action rw_act_insert_Feature_Policy insert_http_header Feature-Policy "\"vibrate \'self\'; sync-xhr \'self\' https://<portalURL.com\""

 

"vibrate 'self'; sync-xhr 'self' https://portalURL.com"

The rewrite policy I will be binding the rewrite action will be as follows:

add rewrite policy rw_pol_insert_Feature_Policy "HTTP.RES.HEADER(\"Feature-Policy\").EXISTS.NOT" rw_act_insert_Feature_Policy

HTTP.RES.HEADER("Feature-Policy").EXISTS.NOT

The last step to bind the rewrite policy to the virtual server will look as such:

bind lb vserver <virtual server> -policyName rw_pol_insert_Feature_Policy -type RESPONSE -priority 150 -gotoPriorityExpression END

As with the previous rewrite policy, be aware of the following configuration in the screenshot above:

Priority – The value will be dependent on what other rewrite policies are currently configured for this VPN Virtual Server.

GOTO Expression – Note that I have configured this value to End instead of NEXT because I this was the last Rewrite action with no other one following.

Adding the Content-Security-Policy, Referrer-Policy, and Feature-Policy header all together

The following are all of the commands bundled into one. Please modify the virtual server and site name as required:

add rewrite action rw_act_insert_Content_Security_Policy insert_http_header Content-Security-Policy "\"default-src \'self\' ; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' ; style-src \'self\' \'unsafe-inline\' \'unsafe-eval\'; img-src \'self\' data:\""

add rewrite policy rw_pol_insert_Content_Security_Policy "HTTP.RES.HEADER(\"Content-Security-Policy\").EXISTS.NOT" rw_act_insert_Content_Security_Policy

bind lb vserver citrix.ccs.bm -policy rw_pol_insert_Content_Security_Policy -type RESPONSE -priority 130 -gotoPriorityExpression NEXT

add rewrite action rw_act_insert_Referrer_Policy insert_http_header Referrer-Policy "\"strict-origin-when-cross-origin\""

add rewrite policy rw_pol_insert_Referrer_Policy "HTTP.RES.HEADER(\"Referrer-Policy\").EXISTS.NOT" rw_act_insert_Referrer_Policy

bind lb vserver citrix.ccs.bm -policyName rw_pol_insert_Referrer_Policy -type RESPONSE -priority 140 -gotoPriorityExpression NEXT

add rewrite action rw_act_insert_Feature_Policy insert_http_header Feature-Policy "\"vibrate \'self\'; sync-xhr \'self\' https://<portalURL.com\""

add rewrite policy rw_pol_insert_Feature_Policy "HTTP.RES.HEADER(\"Feature-Policy\").EXISTS.NOT" rw_act_insert_Feature_Policy

bind lb vserver citrix.ccs.bm -policyName rw_pol_insert_Feature_Policy -type RESPONSE -priority 150 -gotoPriorityExpression END

With the configuration applied, you should now see a score of A from the Security Headers scan:

Securing Citrix ADC (formerly known as NetScaler VPX) to score A+ rating on SSL Labs - February 2020

It has been a while since I’ve updated my previous posts for securing a Citrix ADC (formerly known as Citrix NetScaler) due to my absence from the work force so this post serves to provide the configuration required to published a virtual server to score an A+ on Qualys SSL Labs for the following test:

https://www.ssllabs.com/ssltest/

This post will demonstrate the process on a Citrix ADC NS13.0 47.24.nc via the command line.

Without any additional configuration, a newly published VPN Virtual Server for Citrix Virtual Apps Desktops published by a Citrix ADC typically scores a B or lower:

**Note that SSL Profiles allow the packaging of several SSL settings to be configured and applied to SSL-based Virtual Servers and Services but will not be demonstrated in this post.

Step #1 – Confirm that Deny SSL Renegotiation is configured as FRONTEND_CLIENT

The newer versions of the Citrix ADCs typically have the Deny SSL Renegotiation already configured appropriately but it is always good practice to confirm.

Navigate to Traffic Management > SSL > Change advanced SSL settings:

Confirm that the Deny SSL Renegotiation setting is set to FRONTEND_CLIENT:

Step #2 – Confirm that all available ECC Curves are bound to the virtual server

SSL Virtual Servers created on newer versions of the Citrix ADC such as the version I listed above will automatically have ECC Curves bound to them. However, if the appliance was upgraded from an older version, then the ECC Curves might not be bound.

Navigate into the properties of the virtual server:

Scroll down to the ECC Curve section and confirm that all the available options are bound to the virtual server:

Step #3 – Turn off SSLv3, TLSv1, TLSv11 and enable TLSv12 and TLSv13

The first step is to turn off SSLv3, TLSv11 and TLSv12, TLSv13 on your Load Virtual Server(s) and NetScaler Gateway Virtual Servers. For the purpose of this post, we will use a Virtual Server under the Citrix Gateway (also known as a VPN Virtual Server) for the configuration.

The following screenshots shows where the settings are in the GUI for the VPN Virtual Server:

SSLv3 used to be enabled in the older appliances but the later ones have TLSv1, TLSv11 and TLSv12 enabled by default:

Either uncheck the support for TLSv1, TLSv11 and enable TLSv12 and TLSv13 in the GUI or execute the following command in the CLI:

set ssl vserver <vpn server name> -ssl3 disabled

set ssl vserver <vpn server name> -tls1 disabled

set ssl vserver <vpn server name> -tls11 disabled

set ssl vserver <vpn server name> -tls12 enabled

set ssl vserver <vpn server name> -tls13 enabled

The configuration should look as such once the appropriate protocols are enabled or disabled:

Repeat the same process for the other Virtual Servers in the environment.

Step #4 – Create new custom Ciphers

The following is the set of SSL Ciphers that would allow us to score an A+ SSL scan on a Citrix ADC appliance but note that these need to be continually updated over time what is secure today may be vulnerable tomorrow:

TLS1.3-AES256-GCM-SHA384 -cipherPriority 1

TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 2

TLS1.3-AES128-GCM-SHA256 -cipherPriority 3

TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256

TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384

TLS1.2-ECDHE-ECDSA-AES128-SHA256

TLS1.2-ECDHE-ECDSA-AES256-SHA384

TLS1-ECDHE-ECDSA-AES128-SHA

TLS1-ECDHE-ECDSA-AES256-SHA

TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

TLS1.2-ECDHE-RSA-AES-128-SHA256

TLS1.2-ECDHE-RSA-AES-256-SHA384

TLS1-ECDHE-RSA-AES128-SHA

TLS1-ECDHE-RSA-AES256-SHA

TLS1.2-DHE-RSA-AES128-GCM-SHA256

TLS1.2-DHE-RSA-AES256-GCM-SHA384

TLS1-DHE-RSA-AES-128-CBC-SHA

TLS1-DHE-RSA-AES-256-CBC-SHA

TLS1-AES-128-CBC-SHA

TLS1-AES-256-CBC-SHA

Attempting to use the GUI to create and add the ciphers in can be time consuming and prone to errors. A more efficient way would be to use the CLI and execute the following to create a group named Custom-VPX-Cipher with the ciphers listed above:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 1

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 2

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 3

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-ECDSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-ECDSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

With the above commands successfully executed, we should now see the following Cipher Group created:

Step #5 – Bind new custom Ciphers to Load Balancing Server(s)

With the new cipher group created, proceed with binding them to the Load Balancing Virtual Server(s) and Citrix Gateway Virtual Server(s):

bind ssl vserver www.contoso.com_internal -cipherName Custom-VPX-Cipher
bind ssl vs <vpn server name> -eccCurveName ALL

With the new cipher group binded to the virtual servers, we can use the following commands to review the bindings:

show ssl vserver <vpn server name>

With the new custom CIPHER list bounded, unbind the DEFAULT list that gets bounded to all the virtual servers with the command:

unbind ssl vserver <vpn server name> -cipherName DEFAULT

Browsing to the SSL Ciphers heading for the virtual server should now display the custom Cipher list configured:

Step #6 – Create a Deffie-Hellman (DH) key for Forward Secrecy

The following screenshots shows where to create the Deffie-Hellman (DH) key in the GUI of the NetScaler:

Traffic Management > SSL > Create Diffie-Hellman (DH) key

The CLI command to execute to create the Deffie-Hellman (DH) key is as follows:

create ssl dhparam /nsconfig/ssl/dhkey2048.key 2048 -gen 2

**Note that the process could take a few minutes before completing so wait until the green cursor display changes to a >.

Reviewing the /nsconfig/ssl directory on the NetScaler should now show the dhkey2048.key key that was created:

Step #7 – Assign Deffie-Hellman (DH) key for Forward Secrecy to Virtual Server

With the Deffie-Hellman (DH) key successfully created, proceed with assigning it to the virtual servers.

The following screenshots shows where the settings are in the GUI:

Execute the following command to assign the DH Key via the CLI:

set ssl vserver <vpn server name> -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

Step #8 – Configure Policy for Strict Transport Security – 2 Options

Option #1 – Enable on Virtual Server

As of version 12.0.35.6, a -HSTS ENABLED flag that became available for the Strict Transport Security as shown here:

You can either apply the configuration directly onto the virtual server as such:

Executing the following CLI command would configure the HSTS setting as shown above:

set ssl vserver <vpn server name> -HSTS ENABLED -maxage 157680000 -IncludeSubdomains YES

Option #2 – Create a Rewrite Action and Policy for Strict Transport Security

Another option is to create a rewrite action, policy and then bind it to the virtual server as shown in the following:

Execute the following to create a Rewrite Action for Strict-Transport-Security:

add rewrite action act_sts_header insert_http_header Strict-Transport-Security q/"max-age=157680000"/

With the command above successfully executed, you should now see the following action created:

Execute the following to create a policy and assign the Rewrite Action for to the policy:

add rewrite policy pol_sts_header TRUE act_sts_header

With the Strict Transport Security policy created, proceed with binding them to the virtual servers with the following commands:

bind vpn vserver <vpn server name> -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

With the command above successfully executed, we should now see the Response Rewrite policy bounded to the virtual servers:

Having completed all the steps outlined above should now allow the NetScaler site to score an A+:

There are additional steps that will allow you to obtain a perfect score as the above rating indicates the Key Exchange and Cipher Strength falls just short. The Key Exchange can be updated to use a certificate that is of 4098bit rather than the 2048bit DH Key we used and the Cipher support can be adjusted to remove 128-bit support but the latter change may sacrifice compatibility. Security is a perpetual challenge so the best approach is to constantly update the security hardening configuration on the Citrix ADC to address newly uncovered issues or outdated configuration.

Also note that having less ciphers supported equates to less browser support so it is important to scroll down to the results and review the Handshake Simulation heading that list handshake failures so you are aware of what browsers will no longer be able to access the web application published: