Netscaler & PCI

PCI compliance.  HIPAA compliance.  X compliance.  Y compliance.  Compliance this, compliance that, it’s all the rage these days, right?  What’s a poor Citrix engineer to do?  We aren’t security gurus, we are virtualization guys.  Right?

Well, when the devices we stand up are internet-facing, and they fail a PCI scan, something must be done to correct this situation.  So, I present to you the configuration steps that I recently took to change a PCI scan from failing to passing.  Please note that this is by no means a comprehensive list, individual scan vendors may perform different scans that require other modifications, so you may have additional work to do.  But, these steps should still be considered part of a best practice-type build.

Is your Netscaler physical or virtual?  If it’s a VPX, you need to upgrade to at least 10.5 build 57.7.  11 would be better, but read the release notes first.  Yes, NS11 code is out.  It’s been out for a little over a month now.  I have several of them running, both MPX and VPX.  They are stable, it works great, go get it.  Anyhow – The steps:

Disable SSLv3 and TLSv1 on any vServers:  This one is pretty easy.  Just go to the SSL Parameters on the vServer and make sure TLSv11 and TLSv12 are checked, uncheck SSLv3 and TLSv1.  Be sure to test this with all the devices and different browsers that will be used to access the system.  Some older devices and browsers get bent when you disable TLSv1.  But, the business will have to choose what’s more important – coddling users still on iPhone 4s and Windows XP, or security.  That decision is usually above our pay grade anyway, thankfully.  We can pawn off the reason for the broken devices on the people that made us do it, right?

Removal of eTag headers…  This one proved to be a bit more challenging.  WTF is an eTag header?  Why are they there?  How do I get rid of them?  I’m a virtualization engineer, and I work on Netscaler a bit.  Sure, I might know it better than some people, but I’m not a network engineer.  I’m not a web developer.  I don’t have an intimate knowledge of the HTTP protocol and GETs and POSTs and all this nonsense, and about the closest I come to dealing with headers is X-Forward-For.  So, when I ran across this one, dealing with it was a new one for me.

Go to  Put in a URL, and it’ll come back and give you all the header info.  If you see eTag down there, chances are that the PCI scan company will be angry about it, since it can apparently be used to discover PID info.  Great.

To get rid of this, I used a Rewrite policy.  Pretty easy, actually.  Make sure Rewrite is enabled (hint: it’s under AppExpert).  Then create a Rewrite action and name it “eTag_Action”.  Type is DELETE_HTTP_HEADER, and the Header Name is, you guessed it:  ETag.

Now, create a Rewrite Policy.  Name it something intelligent like eTag_Policy.  The Action should be the action you just created, eTag_Action.  No log action, and leave the undefined-result action alone.  Under expression, enter


Then, just go back to your vServer and link this policy.  It’s a REWRITE RESPONSE policy, BTW.

So, for simplicity’s sake, we’ll assume you’re only dealing with an AG vServer.  You link the policy there, then you point web-sniffer at and there are no eTag headers.  Hooray!  You’re done, right?

Not quite.  Scanning companies are pretty smart, and they’ll scan the individual .js pages (enter into web-sniffer), and look at the 200 responses even.  Crazy, but hackers would do the same thing, so they are just doing what you pay them to do, PITA or not.

So why are there still eTag headers being returned on the .js pages if you told the vServer to strip them?  Because of the caching policies on the AG vServer.  Remove as many as the GUI will let you (there will always be 2 that can’t be removed).  The caching policies are what injects the eTag response even AFTER you stripped it.

Now, if this is a vServer that requires caching, well, you’re going to have to take that up with your internal security guy, the PCI vendor, and whoever has something hiding behind that vServer.  I’m just a lowly little Citrix Geek, not a security guy.  I can’t fix all the world’s problems, but I’ll share the fixes I have found.


Couple of Netscaler command-line tips

Spent some time on the phone with Netscaler support over the past few weeks, and made a note of two commands they used that I found useful.

The first will tell you, in real-time, what policies are hitting when a user logs in via Netscaler:

nsconmsg -g pol_hits -d current

The next will show you traffic, in real time, and let you filter it on IP: host <IP Address>

Not sure if anyone else will find these useful, but I’m sure I’ll be referring back to this post to use them in the future.

Load Balanced,

Comments Off on Couple of Netscaler command-line tips Posted in NetScaler Tagged

It’s the end of Access Gateway as we know it…

Ok, so poor Billy Joel reference aside, Access Gateway really is going away.  Loyal Citrix fans already know that Citrix has been working for quite some time now on making the featuresets between Netscaler and AG the same.  Since they were different code bases, this was a long and time consuming process, and feature parity seemed like it was a pipe dream.  No more!

How has Citrix accomplished this?  Well, they DID spend an awful lot of time working to get Netscaler to support all the same features, of course.  Then, to finalize the whole thing, and give people a single interface by which to configure all those features, they’ve decided to scrap Access Gateway.  Read all about it here.  Basically, what it boils down to is that 31-March-2013 is the End of Sale date for existing Access Gateway product line that is based on non-netscaler code.  Future appliance models will now be known as Access Gateway MPX, formerly Access Gateway 5500.  The new Access Gateway VPX is based on Netscaler code, so you’ll recognize the way it works.  The good news?  Current Access Gateway VPX customers using the non-Netscaler codebase can migrate to the new product for free.

Have an Access Gateway 2010 appliance?  Citrix hasn’t forgotten about you!  Through the end of calendar year 2012 you can “trade up” and get a $3,000 discound off SRP of any new Access Gateway MPX or Netscaler MPX.



Citrix Auto Support??

Just announced at Synergy:  Citrix Auto Support is now publicly available.  What is Auto Support, you’re wondering?  Let me answer that for you!

Auto Support is a Citrix website where you upload logfiles from Citrix Scout (download here) and they get automagically reviewed.  It checks hotfixes and patch levels, detects known issues, compares the environemnt to best practices, and provides a snapshot of the entire environment including servers, versions, settings, storage, CPU utilization, etc.  It currently supports XenServer, XenDesktop, NetScaler, and XenApp.

Documentation on Citrix Scout is published in CTX130147, and Auto Support is available here.  Be sure to read How It Works.