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 web-sniffer.net. 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 https://host.domain.com/vpn/index.html 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 https://host.domain.com/vpn/js/gateway_login_form_view.js 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.