Showing posts with label XenApp. Show all posts
Showing posts with label XenApp. Show all posts

Friday, January 13, 2012

To XenApp or not to XenApp?

There are few tips about Citrix XenApp (ex. Presentation Server, ex. WinFrame) that I would like to share.
Many people, even being involved in technical architecture decisions, are not completely aware of possibilities, dangers and ramifications of this product. They fall to "typical config" patterns that are outdated and do not deliver the best of XenApp.

1. Only publish publishable.

Sometimes XenApp is used as a Remote Access Solution. In this mode, they try to use XenApp as a sort of "gateway" into other internal systems. Well here's the gotcha - if you cannot install and publish a client on XenApp's farm, do not use XenApp. I have seen deplyoments where XenApp was used only to log the incoming user and start a Firefox on the farm. Well, that Firefox could be retargeted to any other internal system, or local file. Plus it could have been used to go online and grab your exploits or code or files from your online accounts. Publishing "open" things is not good. Always try and publish only the final destination apps. If this cannot be accomplished, you're doing something wrong.

2. Browser is not needed.

A typical XenApp installation will include a Web Interface. Now, do you need it at all?
Consider this - starting up a browser, typing and selecting one of bookmarks to navigate to your various Web Interfaces is a drag. Why is it still being used? Only for flexibility of user access, so you could try and access your site from any external of uncontrolled system. Now, what if you have internal, corporate systems that are only accessible to internal clients?
For corporate apps, you should be using Citrix Receiver deployed on client machines, and Citrix Service Site instead of Web Interface. This will improve user experience. Modern Receivers allow users to drag needed icons straight into their Start Menu. One won't need to muck around in a browser to be able to start a pubilshed app. And there's no annoying "bye byes" from Web Interface where you have to re-login due to session expiration.

3. Check your security requirements.

Some still think that Citrix XenApp is a sort of security tool. It is not.
Consider this - you may have 55 users sitting on the same host simultaneously, each user's outgoing sessions have the same source IP. If you have 5 different systems, that source IP has to have route and ACL permissions to go to any system. This means that on network level all 55 users have access to all 5 systems (even though they need not). See why I raised a point 1?
Now to logging. One of your users has managed to run a full internal network scan, discovered some vulnerabilities (sometimes by looking at internal web source code from the published Firefox) and successfully exploited some loopholes, causing service disruption or credetnial leakage). You discovered the issue few hours later, when the farm had [another] 15 users on it. How do you go about tracking suspicious activity to a personal account? In your network logs, it's same IP for all users. On the XenApp host, you have no logs telling you what user had which TCP sockets open at a given moment.
Compare this to VPN now, where everyone has unique IP addresses, hence network permissions and route tables.
One might say - well what about SmartAuditor, a software that can record all user's session as MP4 videos?
OK, so that guy spent 4 hours on legitimate work, then issued a stray command that crashed your system, then kept working for another 3 hours - how are you going to catch it? Watch all 7 hours of his (and other users') videos and following closely everything they were doing? Hardly productive, and certainly not indexable.


4. Secure Gateware deployment.

There are guides on Citrix Secure Gateway deployment. Please be sure to carefully consider what is more important to you. The two main features of CSG are PRE-AUTHENTICATION and WEB-SECURITY.
Pre-authentication means that before your user gets access to your Web Interface, it is authenticated by the CSG.
Web Security mean you're not exposing IIS to externals. CSG offers it's own, sanititzed and locked down environment.
Do not neglect these two, or you will be neglecting the CSG's value. For these reasons, CSG should be deployed in its own box, which is hardened. Do not install Web Interface or other components on the same bax, this will negate the CSG's value or protecting those components.

5. VPN is still a viable alternative.

As already mentioned before, sometimes VPN is a more traceable, transparent solution. You can regulates access on the network level. Different groups can have different ACLs in the network, because they could receive IP from different subnets, or they may receive different routing tables (less secure).
Many negative things about VPN come from the past era of IPsec/L2TP which had it's share of compatibility issues.
Welcome to the age of SSL VPNs. One does not need to go far - Windows 7 (or Vista) support SSL VPN out of box.
If you're a bigger shop, do check out DirectAccess feature in Windows 7/Windows Server 2008R2.

6. Microsoft RDS may fit your bill.

Microsoft has improved and revamped it's Terminal Services to become Remote Desktop Services (RDS).
The new service can give you most of what Citrix XenApp allows, at much more affordable price.
Consider performance, too - XenApp 6.0 is much slower at opening sessions than MS RDS.
Most of XenApp's value - Advanced Load Evaluators, Offline Published Programs etc are rarely used by SMB or even big Enterprises. Being another software, XenApp certainly takes some extra effort in both integration as well as in daily use. Microsoft's offering is certainly better integrated and starts up faster. It also does not require separate skills.
So check your requirements.

7. Some apps are born to be wild.

With Web 2.0 era, more and more applications are moving to the browser (contrary to what I said in point 2 - but that was about way of accessing XenApp). This means that apps are thin enough to be run on any client, and the protocol in between the client and the server is resilient to low-speed or low-quality lines. Lines are getting better every day, so you may need to consider not having any extra "gateways" or VPNs in between the client and the server.
They are all about legacy or insecure software anyway...