Ask Us About... Security, December 2000

By Joel Scambray

Happy Holidays to new and returning AUAS readers this month as I set about answering your questions on Microsoft Windows® security technologies.

Keep Up with Patches!

Before we launch into the Q&A, I want to re-emphasize how important it is for readers to keep up with Microsoft Security Bulletins and patches. If you sort the bulletins by date, you will see that October and November have been particularly busy months for those charged with keeping security patches current. Although all of these patches are important, I want to highlight MS00-078 for Internet Information Server 4 (IIS 4) and Internet Information Services 5 (IIS5) users; move this one up on the list of priorities if at all possible. The fix for this issue is actually a patch that everyone hopefully has applied already. You have, haven't you?

Incidentally, I note in the Microsoft Knowledge Base article for this patch, 269862, that Microsoft Exchange 2000 users should not apply it because of known issues. I have also heard reports of this patch breaking functionality for Microsoft Site Server's LDAP directory service running on Microsoft Windows NT 4® Service Pack (SP) 6a systems. The unofficial Site Server fix that was recounted to me was:

1. Apply the Hotfix detailed in MS00-057.

2. Reboot.

3. Uninstall the Hotfix from a command prompt (see 184305).

4. Re-install SP6a.

5. Re-install the Hotfix.

As always, contact Microsoft Support for more specific questions.

Feeling overwhelmed trying to keep up? Check out the IIS5 Hotfix Checking Tool. HFCheck compares patches installed on a local or remote IIS5 server to a database of available fixes. It then displays an alert or writes to the Event Log when it notes the availability of a patch that has not been installed. "IIS5, heal thyself"—very cool, and another good reason to upgrade to Windows 2000 with IIS5 as soon as possible.

OK, on to the questions!

Read any good Windows 2000 security books lately?

Q: Do you have any recommendations on books and resources describing security practices for Windows 2000 platforms?

A: Well, I gave myself a shameless plug last month (Hacking Exposed, Second Edition is now out with updated Windows 2000 and Internet Explorer and Microsoft Outlook® coverage), so this month I'll point readers to some excellent books that recently won a permanent spot on my personal bookshelf.

I just finished reading (cover-to-cover) Designing Secure Web-Based Applications for Microsoft Windows 2000, written by one of the experts in the field, Michael Howard (with Marc Levy and Richard Waymire). Anyone who is deploying Web applications on IIS5 should be required to read this book. It covers IIS5 security technologies from end to end, authentication to Microsoft SQL Server™ integration. It is stylistically easy to digest, based on the authors' experience securing IIS5 from attack in authentic environments.

For developers, there is Keith Brown's Programming Windows Security, which I also picked up recently. It's down-to-earth, real-world perspective on coding secure applications by using built-in security features of Windows NT/Windows 2000 (including an enlightening discussion of COM+ security) makes for an enjoyable and informative read.

Rename INC to ASP

Before we leave the topic of books, I want to note something that doesn't appear in the pages of the books just mentioned (gasp!), but was recently communicated to me by one of the lead authors (Michael Howard). I have run into this problem a few times in the last few weeks, so I thought I'd share it with readers of this column.

Many IIS developers code their Active Server Pages (ASP) to rely on configuration data stored in external include files (which have the extension .inc). Although ASP scripts are not rendered on the client side browser by default, .inc files, if requested by name, are simply text files that will be displayed to clients. If any private data is stored in these include files (which it shouldn't, but I know it gets in there), it is thus readily accessible to remote users. The simple workaround to this problem is to rename .inc files to have the extension .asp, which will cause them to behave like Active Server Pages and prevent them from being displayed client side. Of course, any internal references within ASP scripts to the old .inc file names must also be changed. I might additionally note that careful use of the <% %> tags or RUNAT=Server syntax in ASP scripts also helps protect inappropriate disclosure of business logic, since they specifically denote code that runs on the server side. These tags actually prevented an older ASP source disclosure attack using malformed HTR file requests.

Terminal Server Security

Q: How does authentication play into remote administration via Terminal Services in Windows 2000? In other words, does an administrator have to authenticate to a Windows 2000 domain before being allowed to remotely access a server?

A: In short, no. You can authenticate to the server machine itself; there is no need to deploy a domain to authenticate against. Here are some additional tips that I picked up from my estimable colleagues at Foundstone who recently deployed a spate of Terminal Services (TS) servers.

First of all, I want to make clear the licensing requirements of TS. TS can be deployed in one of two modes on Windows 2000: Remote Administration mode or Application Server mode. When deployed in Remote Administration mode (as is the goal in the scenario anticipated by this question), TS only allows two concurrent sessions, so don't plan on having squads of administrators connected at any one time to manage servers. Use Application Server mode if you want to have more users share applications on the TS system. (This mode has more complex licensing requirements and changes the performance characteristics of the server on which it is installed.)

Another important thing to recognize about TS on Windows 2000 is that encryption is built in to protect the initial logon exchange as well as the ensuing session data. The default encryption level is medium, which provides bi-directional encryption between the server and the client using RSA Security's RC4 encryption algorithm with a 56-bit key (or a 40-bit key, if you are using an older Terminal Server 4.0 client). Terminal Services also supports 128-bit, bi-directional encryption, which is available if you install the High Encryption Pack. Strong encryption has been eligible for export from the United States to all customers worldwide, except to U.S. embargoed destinations since January 14, 2000; so there are fewer barriers to its widespread deployment. To force clients to connect with 128-bit session security, use the Terminal Services Configuration MMC snap-in (tscc.msc /s). Select the Connections container; right-click on the RDP-Tcp connection object within; select Properties; and on the General tab, set the Encryption Level to "High."

Lastly, never underestimate the power of TS privileges; provide them to trusted personnel only. By default, only members of the Administrators group are allowed to connect to TS when installed in Remote Administration mode.

One of the standard remote administration practices on UNIX systems is to log on as a normal user and then use the "substitute user" (su) command to start a session in the context of a different user account (typically one that can perform more privileged operations than the account used to logon, i.e., Administrator). You may consider implementing a similar paradigm for TS—deny Administrators access to TS, and grant it only to normal user accounts. Those users must then use the runas command (and provide the correct password) to perform duties as Administrator on the TS server. This provides two layers of security for would-be attackers to break. First, they must guess the normal user's password. Then, to escalate privileges, they need to guess the Administrator's password. Depending on the scope of duties to be performed by remote administrators, this may be a burdensome proposition; use good judgment. To manage user access to TS, again go to the Terminal Services Configuration MMC snap-in (tscc.msc /s). Select the Connections container; right-click on the RDP-Tcp connection object within; select Properties; and on the Permissions tab, remove the Administrators group and add whatever group or individual user(s) you wish to provide TS access. Allow the "Guest Access" permission only for all users.

Of course, auditing should be enabled to track all activities performed by remote administrators. And don't forget to log out of TS sessions when work is completed; don't just disconnect. You can force disconnect or end a session after a defined time period using tscc.msc, as described above (on the Sessions tab). This can also be done on a per-user basis via standard Windows 2000 user management tools (compmgmt.msc or Active Directory® Users and Computers).

In past columns, we have discussed alternative secure remote administration tools such as Secure Shell (SSH). One of the advantages of SSH is that its sub-protocols Secure Copy (scp) and Secure FTP (SFTP) allow secure file transfer as well as secure remote command-line management. Terminal Services does not provide an integrated secure file transfer capability, only a remote graphical shell. I noted recently that the first commercial Win32 SSH2 server (that I am aware of) was just released from Van Dyke Technologies. It's called VShell, and it's in beta 2. Check it out.

Of course, there area slew of third-party remote graphical management tools for Win32 platforms, as well. I regularly see Symantec's pcAnywhere, RemotelyAnywhere and AT&T Lab's freeware VNC across many of the environments I encounter in my travels. A discussion of the security strengths and weaknesses of these products is outside of the scope of this column, but can be found in Hacking Exposed, Second Edition, Chapter 13.

Hope this was an informative column this month. Keep those questions coming, and I will answer them in the New Year!

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets & Solutions from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.