I recently was involved in an assignment which involved upgrading Immidio Flex+ to VMware UEM. This upgrade is fairly simple, but can be pretty annoying for end-users, where an upgrade may impact their user experience.

First of all, I will try to explain what group policy extensions are and what they do. Group Policy extensions are extension (well duh) of the standard Microsoft Group Policy objects. They rely on the group policy service, have their own .adm(x) templates and are processed by the group policy engine.

Write comment (0 Comments)

My colleague Arno Meijroos was at a customer where they were experiencing disconnects when using Citrix Receiver 4.6. When the customer used Receiver 4.5 no disconnects occured.

NetScaler was running on Firmware version 11.1.50.10. An MPX was used.

Whilst looking at trace files on NetScaler and Client side all that was noticable was that the connection was terminated on the NetScaler side.

On the NetScaler custom cipher suites were defined to get an A+ rating in SSL Labs.

After working a little with Citrix Support they came with the following work-around:

Unbind the following ciphers from the custom cipher suite.

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

After removing these two ciphers from the suite no disconnects happen anymore.

 

For now I would advice to stay on receiver 4.5 or if there is any need for receiver 4.6 remove the ciphers as described above from your cipher suite.

Write comment (2 Comments)

Recently I have been involved at a customer where we did the NetScaler Gateway implementation. Our good practise is to make sure that we lease the internet accessible IP's with atleast an A rating in SSL Labs.

At the customer I was involved a Pentest was conducted. The pentest was pretty thourough (as expected) and came with a few recommandations. A few of the recommandations related to the HTTP header the NetScaler sends back. This article describes the headers and how to modify this with NetScaler.

 

Content Security Policy

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

How to solve this:

 

add rewrite action rw_act_insert_CSP_header insert_http_header Content-Security-Policy "\"default-src \'self\' ; img-src \'self\' \'data\' ; connect-src \'self\' \'wss\' ; report-uri https://report-uri.io/report/URL;\""

add rewrite policy rw_pol_enforce_CSP TRUE rw_act_insert_CSP_header

Public key pinning

HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.

How to solve this:

add rewrite action rw-act-PublicKeyPin insert_http_header Public-Key-Pins q{"pin-sha256=\"<HASHPRIMCERT>\"; pin-sha256=\"<HASHINTERMEDIATECERT>\"; max-age=2592000; includeSubDomains"}

add rewrite policy rw-pol-publickeypin true rw-act-PublicKeyPin

X-XSS-Protection

This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather than sanitising the script.

How to solve this

add rewrite action rw-act-insert-XSS-header insert_http_header X-Xss-Protection "\"1; mode=block\""

add rewrite policy rw-pol-enforce-XSS TRUE rw-act-insert-XSS-header

X-Content-Type-Options

Nice and easy to configure, this header only has one valid value, nosniff. It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server. It reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as a different content-type, like an executable.

How to solve this:

add rewrite action rw-act-insert-XContent_header insert_http_header X-Content-Type-Options "\"nosniff\""

add rewrite policy rw-pol-enforce-XContent TRUE rw-act-insert-XContent_header

 

Now that all policies and actions are in place we need to bind them to the vServer. Bind them as rewrite/response policy and use the goto expression of next, to make the policy processing continue after applying.

After applying the policies, head over to securityheaders.io hit the URL of your website and see the results:

 

 

 

Write comment (4 Comments)

I was aiding a co-worker with some profile management stuff in a PoC he was doing on Windows 10 and Server 2016. Pointed him out to Workplace and Profiles. He got going with it implemented everything and came back to me with the remark that everything works, but they have a second state key in the registry that has a backup tack between brackets (see picture)

As you can see there is a State [Backup] entry existant in the registry, this also needs to be set to the correct value.

So I added some code to my executable, which is now downloadable in the download section

Write comment (1 Comment)

This week I was at a customer to help them with a NetScaler upgrade. The customer was on a 10.5 firmware and wanted (had to) upgrade to 11.1. So far no problem there.. They have a NetScaler Acces Gateway license, no problem either.. They wanted customization on the Gateway portal, hey no problem. They wanted some links and text on the gateway portal, no problem. Uuuh problem!

After upgrading the secondary appliance, failing it over and applying the rewrite rules, nothing appeared on the Gateway portal..

I suspected Integrated Caching.. As I said, the customer has a NetScaler Access Gateway license. This does not support Integrated caching. When viewing the unlicensed features and looking at Integrated Caching, I did see hits on the default cache groups.

What I did to solve the issue is I went to the gateway portal, opened up the caching policies

Opened the _cacheVPNStaticOBject

And changed the Actions to NONCACHE

After exiting the Gateway Portal setup and refreshing the portal through the internet the rewrite rule was working. As last action I have set the Caching policy back to CACHE.

Write comment (2 Comments)