Remote access requires a higher level of protection. Armed with this task list, you can retain security through NT Terminal Server and the ICA client.

Lower the Bridge! Make Remote Access Secure

Remote access requires a higher level of protection. Armed with this task list, you can retain security through NT Terminal Server and the ICA client.

I know, I know. I’ve preached removing modems from computers and disallowing remote access via dial-in modems on more than one occasion. But my company’s probably a lot like yours. We need access to internal servers, applications, and information when we’re on the road. We have workers who don’t come into the office. So what’s a girl to do—change her mind and allow it? Invest in expensive albeit impressive security doodads like the ones used by the Kansas Bureau of Investigation, as I reported in my April column?

One answer may be to use Windows NT 4.0 Terminal Server Edition with Citrix MetaFrame. It’s not a perfect answer, but what is? Along with providing multi-user capability for NT, Terminal Server adds additional utilities for securing remote access. MetaFrame further defines these utilities, improves speed, and adds additional clients and capabilities. In this month’s column I propose five steps to establish secure remote access using these tools.

First, Some Concepts

You should understand what the multi-user model means, because that’s what Terminal Server uses. In the multi-user model, client software links the client to a software session running on a central server. The server runs the software and sends an NT desktop to the clients. Transport can be maximized, even for dial-up sessions, because only keystrokes, mouse movements, and desktop images cross the wire. Terminal Server provides 16- and 32-bit Windows clients that use the Remote Desktop Protocol (RDP). MetaFrame clients use the Independent Computing Architecture (ICA) protocol and are available for Unix, Windows 3.x, NT, Windows 95/98, Linux, and DOS, as well as Web clients. ICA is also considered to provide the faster transmission of data over dial-up lines. You can obtain additional security by purchasing SecureICA Services from Citrix, which provides a stronger level of encryption for communications between the client and server.

Unlike NT “classic”, there are two types of users with Terminal Server: those with unique passwords and usernames, called explicit users, and generic or guest users, called anonymous users. Anonymous users are created at installation time and are available for use by outsiders to access the Terminal server in a controlled manner. The Web clients can be used to access Web pages on your intranet or Internet server via ICA hotlinks or to launch an Anonymous user session.

Obviously, if you don’t want to provide this type of access, disable Anonymous user accounts.

Step One: Secure the Server

Secure client/server access starts at the server. While you can define Low and Medium security models for Terminal Server (see the docs), remote access requires a higher level of protection. Your goal is to completely protect the file system and registry from malicious attack. (For further elaboration on the following steps, see my article on “Hardening Windows NT” in the October 1998 issue or come to one of this year’s MCP Magazine TechMentor conferences, where I’ll cover it before your very eyes.)

  1. Install NT Terminal Server on an NTFS partition.
  2. Install Citrix MetaFrame.
  3. Make a system backup.
  4. Consider Terminal Server placement in your network. If you’re going to allow Internet access, perhaps it should be outside the firewall; or for more protection, in an inner ring behind the firewall, but isolated from your internal network. If it will strictly be a dial-up server, should you be restricting access to the rest of your network?
  5. Disable booting from 3.5-inch disk.
  6. Disable the BIOS setup prompt (when the system boots, it shouldn’t display an option to enter BIOS).
  7. Use a power-on password (if supported).
  8. Disable shared directories (don’t disable those used by the system, like C$, D$, ADMIN$, and IPC$).
  9. Remove trust relationships.
  10. Disable appropriate network bindings. (Disable all except NetBIOS, Server, and Workstation.)
  11. Enable event auditing.
  12. Take administrator ownership of files and directories.
  13. Set account policies.
  14. Create a profile template or mandatory profile.
  15. Deny logon rights to unused groups (User Manager | Policies | User Rights).
  16. Secure Internet service data (including the Web server and HTML pages; remove read and execute access where appropriate; place scripts in a scripts folder).
  17. Don’t install FTP server service.
  18. Run Internet services at the user level. (If possible, run your Internet server on a different computer; if services are running under a user account, don’t give that user account administrative privileges.)
  19. Remove unnecessary network protocols and services (including NetBEUI, NWLink, NWLink NetBIOS, SAP agent, and Gateway Service for NetWare).
  20. Change event log settings. (Determine if you need to check the setting for the security log to, “Do not Overwrite Events,” then make the log file large and monitor it!)
  21. Audit file and directory access.
  22. Display a legal notice at logon time.
  23. Set the initial start-up program. Specific applications can be started for specific clients or for all users through Terminal Server Connection Configuration.
  24. Delete unnecessary network clients (such as telnet, ftp, tftp, rcp, rsh, rexec finger, lpr, and lpq).
  25. Use policies to restrict users.
  26. Set password restrictions.
  27. Modify the Registry program startup list.
  28. Control access to removable media.
  29. Restrict Control of drive letters and printers.
  30. Audit the system.
  31. Build a new ERD.
Additional Steps for Securing Applications
  • To determine which executable files are needed to run the application, add them as necessary to APPSEC. Some executables may allow users to change settings or perform other desired actions. Add them on a case-by-case basis.
  • Regarding 16- and 32-bit applications: Before you install any applications, disable INI mapping by entering CHANGE USER INSTALL at the command prompt.
  • Install the application to a directory on a local NTFS drive.
  • For 16- and 32-bit applications: Enable .INI file mapping again by entering Change user | Execute.
  • Give Users and Anonymous groups Read and Execute rights only.
  • For DOS applications, set the startup directory to the user’s home directory: %homedrive%%%homepath%.
  • For 16-bit applications, if you’re using APPSEC, add the application’s executable files to APSEC.
  • For 16- and 32-bit applications, create an application definition to launch the executable.
  • For 32-bit applications:
    1. At the command prompt, enter regedt32 to get to the Registry Editor.
    2. Under HKEY_LOCAL_MACHINE, select Software.
    3. Under Software, select MYAPP, where MYAPP is the application you’ve just installed on your server.
    4. Under the Security menu, select Permissions.
    5. Add the Users group using the Add button.
Note: You can also use script files (located in the %systemroot%\scripts directory) to launch applications.

Step Two: Secure the File System

ACLSET is a utility that secures all files and folders on all hard drives. You must then use C2 Configuration Manager [covered in Chris Brooke’s article, "Capture C2 Compliance,” this month.—Ed.] and other tools to selectively enable user access to files and directories. Configuring file security this way ensures that no file system security holes exist. Running ACLSET sets file and directory Access Control Lists to Administrators and sets System groups to Full Control. Other groups and individuals have no privileges.

Step Three: Secure Applications

The Application Security Registration Utility (APPSEC) allows non-administrative users to run a limited set of authorized programs. Secured applications must exist on the local hard drive. Many applications are capable of launching other applications. Using APPSEC ensures that only applications on the application list can be executed, even if you don’t explicitly disable the ability to launch other programs from an application.

Warning! Taking this step on an active server can irreversibly affect its operation. This step should only be taken at system startup.

Troubleshooting Application Issues
Your efforts in “locking down the system” may prevent some applications from working. Try these troubleshooting steps:
  • Enable auditing of file and object access failure on the application directories and on %SYSTEMROOT%.
  • Check the Security Event Log for these events (such as an application trying to create temporary files in its own directory—or trying to modify INI files in the %SYSTEM% root) and adjust access as necessary.
  • Connect to the server as an anonymous user (Run WFICA32 MYDOSAPP.ICA or WFICA16 MYDOSAPP.ICA) and run the application. Does the application run correctly? If not, continue with step four.
  • Check the System Log for “AuthorizedApplications” entries. These notices flag attempts to execute an unregistered application.
  • Make changes to file security and APPSEC based on this information.

Note: Win32 applications may create several registry entries that may not be obvious but are needed for proper operation. To find out if this is the problem, enable registry auditing and use Event Viewer, then set the Registry keys to read access by users.

Using the Application Execution Shell

If applications require writable temporary files or directories to operate, or if they use INI files to define settings and preferences that remain after the application ends, you can manage them with APP.

The APP utility lets you use execution scripts to copy INI files to user directories before the application starts. This same script can perform cleanup after the application terminates. An APP script used in an ICA file can prevent hackers from changing execute parameters.

Access To the Registry and INI Files

Users should be prevented from having write access to the registry; however, some applications need to write to the registry. Because they operate under the authority of the user who started them, access to registry keys for writing may be unavoidable. Find the appropriate keys and properly restrict access to those keys.

Other programs require write access to the directory where their INI files are stored. Avoid these applications to avoid setting write access to server folders. If you must use them, investigate the requirements of each application and limit access to only those folders it needs.

Securing Application Files

Set read and execute access to application program files. Give write access to the temporary directory. To determine if more access is needed, set auditing. In general, don’t give users the ability to customize application environment or change files. If the application is profile-aware, it can be installed to copy user-changeable settings to the user’s profile and maintain them from there.

Securing the File System with ACLSET
  1. Start a command prompt session. Make sure no other programs or users are active.
  2. At the command prompt, type “aclset” and press Enter.
  3. When ACLSET is complete, the command prompt returns. You won’t get a success message, but you will get a report of any errors encountered.

Secure Microsoft System Info

MSI gathers system configuration information. It was meant to be a help tool for support personnel. It can, however, also be used to launch programs, which may allow a security breach or unauthorized information gathering. You can secure MSI by:

  • Setting file permissions on the MSI application to allow execution only by administrators.
  • Using APPSEC to prevent users from executing.
  • Deleting the application from the server.

Don’t Install Application Development Tools

These tools are more difficult to secure. Users shouldn’t be developing their own programs on Terminal Server. Disable the development environments of Excel and Access.

Step Four: Use Security Tools

Use Performance Monitor to warn you of problems. Look for performance degradation, which may indicate virus activity, or track logon attempts, which may indicate attempted break-ins.

Terminal Server has additional security utilities:

  • AUDITLOG generates a report or comma-delimited files of logon/logoff activity from the security event log. This gives you a powerful tool for maintaining system security. You must enable auditing for logon/logoff.
  • ACLCHECK examines the security settings on hard drives and in the system registry, seeking out possible security problems such as objects that seem to have “excessive” security privileges granted or files with write or delete access. Use it regularly and compare each new run to the previous. You can investigate new files and directories or those with security changes to see if they represent security breaches.
Using APPSEC
  1. Go to Programs | Administrative Tools | Application Security.
  2. Click “enabled” in the Security box on the Authorized Applications dialog box.
  3. Click “Add”.
  4. Enter path and program executive name.
  5. Repeat steps four and five to add all desired applications.
  6. Don’t attempt to remove (add if absent) the following applications from the wtsrv folder: explorer.exe, systray.exe, cmd.exe, subst.exe, xcopy.exe, net.exe.regini.exe, or %SYSTEMROOT%system32\app.exe.

Note: You can also use script files (located in the %systemroot%\scripts directory) to launch applications.

Step Five: Create and Deploy Secure Clients

MetaFrame installs extensions for configuring ICA connections and managing ICA sessions. You need to configure connection settings as well as individual user and per-client settings.

Per-Connection Settings

You set per-connection settings in the Terminal Server Connection Configuration utility. Connections define the remote control session and are associated with network (IPX/SPX, TCP/IP, and NetBIOS) or serial (modems or direct cable) settings. You can override connection settings by per-client settings if the “inherit user config” check box is selected.

  • Restricting user to published applications. Applications are published using the Application Configuration Utility. Restricting the connection to published applications keeps users from running unapproved software on your system.
    Using modem callback. After a connection is established, MetaFrame will disconnect and dial back a preconfigured number. This can prevent calls from unknown users.
  • Security. If SecureICA services has been installed, 40-, 56- or 128-bit RC5 encryption can be selected. Otherwise Basic encryption (dependent on the client type) is used.
  • Client device mapping. Device mapping determines the availability of client resources (such as drives, printers, and the Windows Clipboard) during the remote session. Since the availability of these resources may allow copying of sensitive information, manage them carefully.
  • Session Shadowing. Shadowing allows the monitoring of the remote session display and use of the remote session keyboard and mouse. Disconnected sessions (in which the user hasn’t logged off and processes may still be running) can also be monitored. While you can use this tool to troubleshoot and train, you can also monitor suspicious activity on your system with it.
  • Audio bandwidth restriction. If users have sound cards in their systems and applications running on the server have sound, then users can hear the sound locally. Restricting audio bandwidth may be necessary to assure bandwidth availability for other sessions.

Per-User Settings

Per-user settings are configured with User Manager. Remember: Use modem callback; specify client device mapping.

Per-Client Settings

Configure per-client settings with the Remote Application Manager (MetaFrame 1.0) or Program Neighborhood (MetaFrame 1.8). SecureICA Clients can be configured to allow changing of security settings so connections can be made to servers with varying encryption strengths. Also, concern yourself with audio bandwidth restrictions.

Securing Client Installations and Connections

Files for creating ICA clients are in the %systemroot%\System32\Clients\Ica folder. Secure this folder to control client creation. Secure the MetaFrame CD-ROM, as clients can be created directly from the CD-ROM.

Remote connections can be established as remote control or remote node plus remote control. In the remote control connection the Remote Application Manager on the client manages the connection to a modem on the MetaFrame server. Remote node plus remote control requires establishing a connection to the NT RAS server and then a remote connection. You can achieve additional security with a RAS configuration. Only the Win32 ICA client (Windows 95/98 or NT) can use this method.

Don’t forget to create client disks and distribute in a secure fashion.

Also, a scripting language is available for ICA DOS, Win16, and Win32 clients. Scripts can be written to configure connections that go through additional security devices for authentication before starting an ICA session.

Additional Information

No, It’s Not Easy

Achieving remote access won’t be the easiest job you’ve ever tackled, but face it: Your real responsibility is to secure the premises as best you can given the realities of your environment. When road warriors come knocking at the fortress gate, somebody needs to let them in. Might as well be you, the person who’s heard of every trick in the book.

Featured

Most   Popular