Securing Your Thin or Lean Client/Server Environment

So you've finally decided to deploy a thin or lean client/server Windows NT solution. Have you thought about how the new alternative NT deployment options will affect the security infrastructure of your enterprise network? You need to answer this crucial question before you start breaking ground and pulling cables. To help you, I'll discuss the security implications of three technologies--remote console, API redirection, and client-side persistent caching--found in several popular thin and lean client/server solutions. I'll also identify several architectural points to consider as you meld these distributed computing solutions into your existing security model.

Remote Console
Products such as Citrix Systems' WinFrame and Microsoft's Windows NT Server 4.0, Terminal Server Edition incorporate remote console technology. In a remote console environment, applications execute as part of a virtual console session on the server. In other words, the application logic in a console session executes on a centrally administered server.

Securing a remote console environment might appear to be an easy task because it allows central administration. But, as many veteran WinFrame administrators can attest, securing a server when users have console access can be challenging. Here's why: If you give users a complete NT desktop, they'll likely poke around the Start menu, the Administrative Tools, and other sensitive areas. Giving a locked-down NT desktop to curious (or malicious) users is risky. A disruptive action, such as launching a misbehaved DOS application (e.g., edit.com consumes numerous CPU cycles), can affect hundreds of connected users because the console runs on a multiuser server.

An obvious way to prevent disruptions is to dedicate a user logon session to one application. In this configuration, the connected users see only the application that the administrator assigns to their profile. Because there's no desktop and no Start menu, there are no problems, right? Not exactly. In several documented cases, users have bypassed this configuration by executing a macro or utility from within an application. For example, in Office 97, users can invoke the MS Info utility from the About dialog box in any of the suite's applications. The users can then use the Run Start menu command to launch another program. If they start Explorer, they can access Desktop. From Desktop, users can perform many feats, such as using My Computer to browse the file system and launching even more applications from the Start menu--a complete security breakdown.

The solution to this backdoor hack (and similar breaches) is to know your applications and disable loopholes. With Office 97, for example, you can uninstall the MS Info utility. (You can find this option in the Office Setup program.) In other applications, you might need to delete or rename the offending executables or .dll files.

In Terminal Server, you can also prevent security breaches by enabling the Application-Level Security feature. With this feature, you can tell Terminal Server to restrict access to certain applications. If you enable this feature, use System Policy Editor (SPE) to create policies, and judiciously apply NTFS access control lists (ACLs), you can effectively lock down a Terminal Server-based remote console environment.

The bottom line with multiuser security is to be proactive. Know your applications and constantly search for potential security breaches.

API Redirection
Unlike remote console environments, API redirection platforms, such as New Moon Software's Liftoff, use the existing NT process architecture to initialize and execute new applications. A server-side redirector then traps certain high-level interface APIs (e.g., the application's GUI) and redirects them over the network to the clients. As a result, API redirection platforms are not vulnerable to backdoor hacks.

However, API redirection environments are vulnerable to another type of security breach. If an application's server-side process can act as a component object model/Object Linking and Embedding (COM/OLE) container, users with programming knowledge can redirect that process so that it instantiates another object (either in process with a .dll file or externally). The users can then use the object to probe the system at the API level. A Liftoff-enabled implementation of Microsoft Internet Explorer (IE) is particularly vulnerable to this type of attack. Users need only point IE to a Web page with ActiveX containers to gain control of the session.

To eliminate this security breach, you need to proactively lock down loopholes in obvious places (e.g., ActiveX object instantiation) and not-so-obvious places (e.g., a macro executing Dynamic Data Exchange--DDE--commands to another process). Fortunately, the developers of Liftoff planned for such breaches. Liftoff uses the LogonUser() and CreateProcessAsUser() Win32 API functions to ensure that applications execute within a well-defined security context.

Still, you need to watch for programmatic loopholes, and you need to leverage administrative lock-down tools, such as the Internet Explorer Administration Kit (IEAK). A solid understanding of how the underlying technology works is your first line of defense.

Client-Side Persistent Caching
If you're looking for hacker-proof thin-client technology, client-side persistent caching environments, such as EPiCON's ALTiS and Microsoft's IntelliMirror in NT 5.0, are about as close as you can get. This technology offers the benefits of centralization without the risk of a remote user hacking a server-side process.

In both ALTiS and IntelliMirror, the client locally caches the server-based application code. On request, the client PC's cache manager downloads the application code, which the client then executes. In the case of ALTiS, the server simply acts as an intelligent virtual storage mechanism--an extension to the client's file system that seamlessly integrates the cached code. In the case of IntelliMirror, the server integrates IntelliMirror with Active Directory (AD) to provide authentication and redirection services for the extended class store as part of the automated Microsoft Installer (MSI) service.

In both ALTiS and IntelliMirror, the server-side cache manager handles all redirection, placing the client at the mercy of the server. If someone were to hack into the ALTiS server through Internet Information Server (IIS) and Internet Server API (ISAPI) or into the AD server through a not-yet-discovered loophole, that hacker can potentially wreak havoc by redirecting thousands of users to a bogus server-side code store.

Such a hack, however, likely requires a fundamental breakdown in network security. (Because ALTiS uses ISAPI, it's a bit more exposed than IntelliMirror.) In addition, the same threat exists in all environments in which users are running executables that the server centrally stores. So, if you have the basic security protocols (e.g., firewalls, ACLs on all resources, security patches, and hotfixes) in place, a product with client-side persistent caching technology is a safe option for sensitive deployment environments.

The Old Lessons Still Apply
Although NT now has alternative deployment options, the basic principles of network security still apply: Leave no resources unprotected. Regularly conduct security sweeps to look for points of exposure. And have a well-enforced policy of password maintenance and multilevel authentication.

In the end, ignorance is your biggest enemy. As an enterprise systems administrator, you need to fully understand the architectural characteristics of the thin or lean client/server product you deploy. If your product works in a remote console environment, you must know which applications can run an executable or command. If your product uses API redirection, you must know how seemingly innocent features (such as COM/OLE) can be harmful in the wrong hands. If your product applies client-side persistent caching, you must know about the potentially catastrophic single point of failure built into the architecture.

Experience dictates that hackers can break into any system, including alternative NT application environments. But you can discourage most hackers by effectively locking down your system.