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.
- By Roberta Bragg
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
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
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.)
- Install NT Terminal Server on an NTFS partition.
- Install Citrix MetaFrame.
- Make a system backup.
- 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?
- Disable booting from 3.5-inch disk.
- Disable the BIOS setup prompt (when the system boots,
it shouldn’t display an option to enter BIOS).
- Use a power-on password (if supported).
- Disable shared directories (don’t disable those used
by the system, like C$, D$, ADMIN$, and IPC$).
- Remove trust relationships.
- Disable appropriate network bindings. (Disable all
except NetBIOS, Server, and Workstation.)
- Enable event auditing.
- Take administrator ownership of files and directories.
- Set account policies.
- Create a profile template or mandatory profile.
- Deny logon rights to unused groups (User Manager |
Policies | User Rights).
- Secure Internet service data (including the Web server
and HTML pages; remove read and execute access where
appropriate; place scripts in a scripts folder).
- Don’t install FTP server service.
- 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.)
- Remove unnecessary network protocols and services
(including NetBEUI, NWLink, NWLink NetBIOS, SAP agent,
and Gateway Service for NetWare).
- 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
- Audit file and directory access.
- Display a legal notice at logon time.
- Set the initial start-up program. Specific applications
can be started for specific clients or for all users
through Terminal Server Connection Configuration.
- Delete unnecessary network clients (such as telnet,
ftp, tftp, rcp, rsh, rexec finger, lpr, and lpq).
- Use policies to restrict users.
- Set password restrictions.
- Modify the Registry program startup list.
- Control access to removable media.
- Restrict Control of drive letters and printers.
- Audit the system.
- Build a new ERD.
Steps for Securing Applications
Note: You can
also use script files (located in the
%systemroot%\scripts directory) to launch
- 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
- 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:
- 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:
- At the command prompt, enter
regedt32 to get to the Registry
- Under HKEY_LOCAL_MACHINE, select
- Under Software, select MYAPP,
where MYAPP is the application
you’ve just installed on your
- Under the Security menu, select
- Add the Users group using the
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.
|Your efforts in “locking
down the system” may prevent some applications
from working. Try these troubleshooting
- 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
- 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.
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
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.
the File System with ACLSET
- Start a command prompt session.
Make sure no other programs or users
- At the command prompt, type “aclset”
and press Enter.
- 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
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
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
- Go to Programs | Administrative
Tools | Application Security.
- Click “enabled” in the Security
box on the Authorized Applications
- Click “Add”.
- Enter path and program executive
- Repeat steps four and five to add
all desired applications.
- 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.
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.
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
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
- 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
Per-user settings are configured with User Manager. Remember:
Use modem callback; specify client device mapping.
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
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.
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.